VERSUS: Preprocesadores CSS, ¿sí o no? Esa es la cuestión.

Juan Francisco del Río

Jaime, tú siempre eres muy de modas, acuérdate cómo Google Wave te pareció lo más y te volcaste con ese nuevo lenguaje de programación del que hoy sólo hablas tú en StackOverflow.

Hay dos peculiaridades de mi workflow con CSS que me hacen desentonar respecto a las costumbres de la mayoría de los desarrolladores front: prefiero el código compacto (un espacio separando propiedades, una línea por selector) y no suelo usar preprocesadores.

Uno de los principales motivos de no usar un preprocesador es común a preferir el código CSS compacto: la legibilidad del código, como escaneo el código mientras desarrollo y obtener más información de lo que veo.

Por eso alguna de las características de los preprocesadores no me gustan. Los nesting me parecen menos legibles que como sería en CSS vainilla. Los mixins, extends o variables pueden obligarme a ir a su definición para ver que se está aplicando.

Otro motivo es la pereza, tengo que ver ventajas muy claras para añadir una nueva capa de abstracción, aprender una nueva sintaxis y tener que utilizar herramientas nuevas para la compilación. Y la verdad es que no veo claras las supuestas ventajas de usar un preprocesador y perder algo del control sobre el CSS final. También es motivo de pereza pensar el tener que tocar un proyecto dentro de dos años que usa un preprocesador ya en desuso. Algunas de las utilidades que ofrecen los preprocesadores ya las encuentro como plugins en mi editor (sublime), por ejemplo autoprefixer o csscomb.

Prefiero no caer en la tentación de caer en la sobreingeniería llenando el código de las típicas estructuras de programación (if/else, for, funciones), de variables, mixins. Un código más difícil de mantener y de leer si no eres el autor del mismo. Dejemos el CSS lo más sencillo posible.

He visto muchos ejemplos de CSS "feo" generado por un preprocesador. Imagino que te puedes venir arriba con las inteligentísimas características del preprocesador de turno y no darse cuenta de lo que está generando finalmente. Algunas veces los mixins, extends y bucles los carga el diablo.

Debugear también resulta más complicado, los source maps no son una solución para todos los navegadores, los más obsoletos no implementan esa capacidad.

Jaime Fernández Pérez

Juan, tú ya peinas canas o casi, y tienes los cajones llenos de CDs con utilidades de la PC-World "por si acaso" y miras estos avances con más recelo que un gato frente a un espejo.

¿Pero de verdad alguien todavía tiene dudas? Preprocesadores sí, sí y siempre sí. Nos facilitan tener código ordenado, potente, legible, y mantenible.

El código compacto y ofuscado para las máquinas, nosotros somos humanos (de momento) y necesitamos código con el que sea agradable trabajar. Pequeño y estructurado.

No nos engañemos, el CSS no es el lenguaje más potente y los preprocesadores dotan al CSS de características que debería de tener por sí mismo: variables, mixins, bucles, includes...

La legibilidad de código es infinitamente más limpia con SCSS (siempre que se use bien). Al no tener selectores repetidos facilita la ordenación y, al colapsar los bloques, haces que puedas localizar con gran facilidad la porción de código que buscas.

Facilita la reutilización de código, permite tener un código más limpio y más mantenible. Las variables te facilitan el mantenimiento, los includes el tener tantos ficheros como quieras, cada uno encargado de una pequeña parte (botones, formularios, textos, cabecera, footer...) y luego compilarlos en un único fichero CSS. De este modo es más sencillo encontrar dónde debes tocar. Antes tenías que buscar un selector dentro de un fichero de varios miles de líneas.

Los source maps ya no son un problema y, a día de hoy, debuggear el código es tan sencillo como el CSS.

El único punto que podría aceptar como negativo es que es necesario compilar los ficheros para obtener el CSS resultante, pero a día de hoy esto ya no es un problema, existen multitud de programas que hacen esta tarea en segundo plano y en milisegundos.

La curva de aprendizaje es mínima, ya que puedes empezar usando simplemente la anidación y poco a poco empezar a sacar partido a los mixins, extends, bucles... Hasta un diseñador puede empezar a ser productivo en una sola tarde.

Dicho esto, no quiero parecer el loco de la "sobre-ingeniería" y solo apoyo lo que claramente funciona bien y es útil para tu proyecto, en ocasiones se abusa de sus posibilidades.