5 Mitos de los Pre-Procesadores de CSS

Cristalab es la comunidad donde aprendí muchísimo de lo que uso hoy en día en mi trabajo. Desde hace dos años que vivo en Londres, Inglaterra y trabajo en una Agencia Digital llamada Cyber-Duck Ltd como Front End Developer. Los que me conocen por aquí, saben que llevo unos 10 años trabajando en internet, que amo mi trabajo y también que me encanta hablar y escribir sobre este tema.

Recientemente fui invitado a hablar en una conferencia sobre diseño web, y escogí hablar sobre los mitos de los pre-procesadores de CSS. Durante mi investigación, Freddie me ayudó a distribuir una encuesta que probablemente muchos de ustedes llenaron, sobre el uso de estos. Aquí están los resultados junto con el resto de la charla.

¿Qué son los Pre-procesadores de CSS?

Yo los veo como un método de agregar dinamismo a un lenguaje muy estático como lo es CSS. Este dinamismo viene en forma de funciones, variables, mixins y extends.

Porcentajes de Uso

En mi encuesta procuraba determinar el porcentaje de uso de los diferentes procesadores disponibles actualmente, así como el porcentaje de gente que no usa ninguno. Esto es lo que descubrí:

Latinoamerica: En este gráfico, podemos ver como un altísimo porcentaje de desarrolladores no utiliza ningún tipo de procesador de CSS (alarmante!).


Europa: Podemos ver como no solo el porcentaje que no utiliza ningún procesador es notablemente inferior, sino que además la gran mayoría de desarrolladores tiene Sass como su procesador preferido.

¿Por qué usar pre-procesadores?

Muchos desarrolladores tienen razones particulares para usar (o no usar) un procesador de CSS específico, pero las más comunes son las siguientes:

• CSS es repetitivo.
  
• CSS no tiene variables.
  
• Es Inflexible, y complicado de reusar.
  
• Sitios web complejos se vuelven complicados de mantener.
  

La inhabilidad de anidar selectores obliga a repetirlos una y otra vez al escribir CSS común. La falta de variables hace que el código no sea reusable, ya que detalles específicos como colores, tamaños y fuentes tienen que ser escritos directamente en cada hoja de estilos.

Los mitos

En orden de popularidad de menor a mayor:

• Disminuye el rendimiento a los sitios.
  
• Agrega complejidad al proceso de desarrollo.
  
• Tiene dependencias que deben ser cubiertas.
  
• Se pierde control sobre el código final.
  
• Muy complicado de depurar.
  

Bull. Crap.
Vamos a desmentir uno a uno estos mitos:

Disminuye el rendimiento a los sitios

Este mito proviene del hecho que Less está basado en un compilador escrito en JavaScript que es capaz de compilar “en vivo” una hoja de estilos, por lo que muchos principiantes publicaron las hojas de estilo en archivos Less en vez de pre-compilarlas para producción.

Todos los procesadores compilan el código a CSS común y corriente, el cual además puede automáticamente ser comprimido y minificado para reducir tamaño de archivo. Por otro lado, facilitan el concatenar varios archivos en uno solo para reducir HTTP requests, por lo tanto de puede decir que aumenta el rendimiento, no lo disminuye.

Agrega complejidad al proceso de desarrollo

Anidar selectores se hace natural al escribir código, de la misma forma que las variables son naturales en muchos lenguajes y representan una forma más fácil de lidiar con valores que se repiten a lo largo de la hoja de estilos.
Al final, no es obligatorio usar toda la funcionalidad de Sass para que sea productivo, e incluso puedes escribir CSS plano y Sass lo procesará como si nada (No Less ni Stylus), de esta forma puedes empezar a usarlos y poco a poco ir incorporando la funcionalidad.

Tiene dependencias que deben ser cubiertas

Por un lado, todo entorno de desarrollo tiene sus dependencias, y las de procesadores de CSS no son en ningún caso complicadas o difíciles de instalar y configurar. Por otro, en la web de hoy en dia, si no usas un pre-procesador, necesitas un post-procesador (a menos que seas un completo masoquista).

Agregar prefijos de navegador, o simplemente minificar el código es prácticamente automático con cualquier pre-procesador, de lo contrario es necesario el paso extra usando alguna herramienta externa para lograr este objetivo. Mas adelante hay una lista de herramientas que facilitan este proceso.

Se pierde control sobre el código final

Sass no se escribe por sí solo. Esto significa, que si tu código final es horrible, tu código Sass es horrible (y muy probablemente tu actual CSS tambien es horrible).

Todos los pre-procesadores actuales tienen la opción de compilar código en su forma expandida, con comentarios y saltos de línea, etc, para que puedas revisar tus selectores, y el estilo durante el desarrollo, y así identificar posibles problemas o detalles que puedan mejorarse.

Muy complicado de depurar

Si escribes código organizado, no debería ser complicado de depurar. Usar archivos separados para cada componente o sección de tu sitio e importarlos con @import, esto ayuda mucho para depurar, al final todos se concatenan en un solo archivo para producción.

El proceso está mejorando día a día, incluso las últimas versiones de Chrome Canary (versión de desarrollo) incluyen soporte a “sourcemaps” con Sass (solo versión 3.3) que mapean los archivos Sass en vez del archivo CSS, indicando archivo original y número de línea de la regla inspeccionada, facilitando su localización.

En mi experiencia, el costo de la depuración es muy bajo comparado con el beneficio de usar procesadores.

Recursos

Siempre recurre a la documentación, los tres principales pre-procesadores cuentan con muy buena documentación online, haz buen uso de ella.

Esta es una lista (no exaustiva) de herramientas gráficas que ayudan en el desarrollo, para Mac, para Windows, algunas multiplataforma, unas de pago y otras gratis:

• Codekit
  
• Prepros
  
• Compass
  
• Hammer
  
• Koala
  
• Mixture
  
• LiveReload
  
• Scout
  
• Crunch
  
• SimpleLess
  
• WinLess
  
• LessApp
  

Otras herramientas interesantes son Grunt! Buildr y Brunch.io que además hacen muchas otras cosas.

¿Cuál es el mejor?

En mi opinión, Sass tiene varias ventajas como lo son su rápido y activo desarrollo, soporte de grandes empresas (Google), y el hecho de que su estilo es muy parecido a CSS hace el cambio aun más fácil, aparte que es el único que actualmente soporta Sourcemaps (Less está en proceso de implementarlo, Stylus lo está considerando). En cualquier caso, asegúrate de que la opción que elijas se adapta bien a tu proceso y que simplemente se sienta bien en tu caso particular. Si todavía no lo usaste, aquí tienes una Introducción a Sass y Compass.

Cabe mencionar, que es importante saber cómo funciona CSS antes de intentar usar un pre-procesador, ya que ésta es la mejor forma de saber que tu código esta bien escrito y bien estructurado.

Espero que este artículo te ayude a tomar una buena decisión con respecto a los pre-procesadores de CSS, y por cualquier duda, pregunte.

¿Sabes SQL? ¿No-SQL? Aprende MySQL, PostgreSQL, MongoDB, Redis y más con el Curso Profesional de Bases de Datos que empieza el martes, en vivo.