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

Desde Paradigma hemos querido crear una nueva serie de artículos en los que se enfrenten entre sí tecnologías, metodologías, frameworks… Desde el departamento de Front hemos decidido romper el hielo con un enfrentamiento muchas veces visto en la cafetería: Preprocesadores CSS ¿sí o no? ¿Merece la pena usarlos? ¿Cuáles son sus pros y sus contras?

Pretendemos poner un poco de luz en el tema y esperamos que tú también nos des tu opinión. Y no te cortes en comentar, sé talibán en tus opiniones y cuéntanos por qué tú estás a favor o en contra de los preprocesadores CSS.

css_vs_sass

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.

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.

y tú, ¿Qué opinas?

Un título en alguno de mis cajones dice que soy economista, pero desde hace ya más de 15 años me siento Front developer, aunque por esos entonces nos hacíamos llamar Web Master ;-). En la actualidad: orgulloso miembro decano del departamento de Front de Paradigma; obsesionado con desarrollar interfaces de usuario intuitivas, eficientes y bien diseñadas para cualquier tipo de dispositivo; y responsable de vissit.com.

Ver toda la actividad de Jaime Fernández

Recibe más artículos como este

Recibirás un email por cada nuevo artículo.. Acepto los términos legales

8 comentarios

  1. Luis Calvo dice:

    Jaime ¿milisegundos en compilar? Eso si estás haciendo el blog de ganchillo de mi tía-abuela. En el proyecto en el que estoy tarda hasta 11 segundos en compilar tanto mixin y tanto extend. Si tuviera ahora todos esos 11 segundos gastados podría haber actualizado mi pobre blog.

  2. Abby dice:

    Buen artículo! :-D

    Mi “yo” normal dice: he probado LESS y SASS, aunque no he profundizado mucho, pero no me ha enganchado. Algunas cosas me gustan, pero por ahora han podido más los contras que los pros…

    Mi “yo” talibán dice: esto del front se está convirtiendo en una locura, quiero un “slow front code”, o algo así… Se harían votos diarios por la sencillez, el código limpio, y recuperar el espíritu artesano. Relaxing code! ;-)

    • Javi dice:

      Abby me uno a tu “yo” talibán. En http://www.slowmovement.com/ falta “slow code”. De hecho podríamos abrir otro debate tirando de este hilo… ahí lo dejo

      • Paradigma Digital dice:

        ¿Pero podemos hacer fast & fashion apps con slow code? La página de Slow Movement no está maquetada con tablas, pero casi ;-)

        • Abby dice:

          @Javi, ya somos dos, ¿será el germen del slow coding? ;-) Venga ese debate: ¿es posible actualmente un slow coding? ¿cómo podemos definirlo?

          @Jaime, podemos hacer fast and fashion apps haciendo slow coding, y es más, seguro que la calidad aumentaría.. Pero, como demuestra la web de Slow Movement, se sigue necesitando un buen diseño primero ;-D

          La cuestión es mantener la calma en el “frente” aunque lleguen balas de fogueo (modas), o nuevas e impresionantes armas que debemos saber cuándo usar.

  3. David dice:

    Mejor CSS + plugins/postprocesadores. Añadir una capa de abstracción que encima te da muuucha cuerda para ahorcarte si no tienes cuidado no compensa.

    Eso y un poco de paciencia: https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_variables

Escribe un comentario