Author: koas

Últimamente he leído bastantes artículos por ahí en los que la gente se queja del estado actual del desarrollo web. La principal queja es que aun teniendo conexiones de alta velocidad la páginas siguen cargando lentas. En estos dos artículos lo explican perfectamente:

• The bullshit web
• Dear developer: the Web isn’t about you

Leyendo estos artículos me reconocía en la sensación de hartazgo que supone que una página de noticias (que es básicamente texto y fotos) se vea a trompicones en un ordenador de 16GB de RAM obligándome a usar una extensión para desactivar JS en ese tipo de páginas.

Pero también me di cuenta de que yo mismo he contribuido a ese estado de la web actual. Mis últimos proyectos no funcionan sin JS. Usuarios con navegadores antiguos no pueden acceder a la información que se supone que mis páginas deberían ofrecer. Reconozco mi culpa.

No basta con reconocer la culpa, es necesario además tener espíritu de enmienda. Y fue al leer este breve libro, Resilient Web Design, cuando decidí que había llegado el momento de ser coherente y cambiar el enfoque que tengo con el desarrollo web.

Así que me he propuesto un reto para cumplir antes de fin de año. Voy a desarrollar una web que cumpla los siguientes requisitos:

• Cargue y pueda empezarse a usar en menos de tres segundos.
• Funcione aunque el usuario desactive JavaScript / CSS en su navegador.
• Bonus: la web debe funcionar con las versiones más antiguas que pueda encontrar y usar de Netscape Navigator e Internet Explorer.

Escribiré entradas aquí con todo lo que me vaya pareciendo interesante del proceso. ¡Deseadme suerte!

Llevo un tiempo estudiando Vue.js y me gusta bastante. Lo que más me gusta es poder tener los componentes separados en ficheros .vue con su HTML, CSS y JS.

El problema es que estos ficheros .vue no se pueden usar directamente, hay que convertirlos, y para eso se requiere webpack o browserify o algún programa similar. Aprender a usar estos programas no es trivial, y lleva su tiempo.

Hay un paquete de Node, VUE cli, que permite crear un esqueleto de aplicación para Vue que ya tiene configurado webpack para “compilar” los ficheros .vue, pero no me convence porque aunque quizá para una aplicación que empieces desde cero puede valer no tengo muy claro cómo incorporarlo a un proyecto ya existente (quiero usar Vue para hive.ly).

Total, que al final he hecho un pequeño script al que le pasas tres parámetros:

• La carpeta donde están los ficheros .vue
• La ruta de un fichero js
• La ruta de un fichero css

y genera un fichero js y otro css con el código y los estilos de los ficheros .vue. Basta con cargar estos dos ficheros en nuestra página y ya podremos usar los componentes.

El script está disponible en GitHub y requiere que tengamos instalado PHP en nuestro ordenador.

El único requisito que deben cumplir los ficheros .vue es que el parámetro template de la llamada a Vue.component debe ser una cadena vacía con backticks: “

Ejemplo de fichero .vue:

<template>
	<div>
		<button v-on:click="count++">
			You clicked me {{ count }} times.
		</button>
		<image-counter></image-counter>
	</div>
</template>

<script>
Vue.component('button-counter', {
  data: function () {
    return {
      count: 0
    };
  },
  template: ``
});
</script>

<style>
button {
	background: red;
}
</style>

Si tenemos una columna en MySQL que contiene valores separados por comas, por ejemplo 1,3,5, podemos buscar los registros que tengan un 3 en esa columna usando:

SELECT id FROM tabla WHERE 3 IN (nombreColumna)

Este es un ejemplo de una publicación de OpenMags incrustada en un blog.

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.