Buscando al arquitecto de Frontend

Existe un sentimiento o idea demasiado extendida entre desarrolladores (1) de aplicaciones web. La idea, en líneas generales, viene a decir que en la expresión aplicación web, aplicación significa "lo que hacemos en el servidor" y web significa "batiburrillo de HTML y Javascript". O dicho de otro modo, que la parte web del desarrollo, en cuanto hacemos algo medianamente complejo (i.e. una aplicación), va a ser necesariamente un caos.

No todo el mundo piensa así (por suerte), pero sí es una idea enormemente extendida. La idea, aclaro, no es que pueda ser un caos, sino que necesariamente va a serlo, que así es como es. Esto, en mi modesta y habitualmente errónea opinión, se cimenta en algunos errores fundamentales y en una causa muy concreta.

La aplicación es lo que hacemos en el servidor

Muchas veces explícita y más veces implícita, esta parece ser la idea que empapa las mentes de los arquitectos (2) y, seguramente, los ahoga. Los aspectos que toma esta idea son diversos, pero en general se suele sentir como la idea de que lo que se hace en el servidor es lo realmente serio, es donde está la lógica de negocio y donde hay grandes máquinas y grandes códigos corriendo en ellas.

Esta idea, como decía, es errónea. ¿Por qué? En primer lugar porque la aplicación es todo, porque no podemos hacer una aplicación web sin la parte web. Pero más aún, porque en varios aspectos, esa parte web es mucho más importante y seria que lo que hay en el servidor.

El inevitable batiburrillo del Frontend

Esta es la otra idea fundamentalmente errónea: Que es inevitable sufrir en el Frontend. Y la vemos en muchos aspectos. Odio irracional a Javascript (a veces también a HTML y/o CSS), sueldos más bajos para trabajos de Frontend e incluso la curiosa idea existente en algunos sitios de pensar que los desarrolladores empiezan haciendo Frontend y luego aprenden más y van pasando a servidor escapando del infierno.

El error que se comete con esto es que si el punto de partida es así de negativo, ni siquiera intentaremos hacerlo bien. Todo lo más buscaremos soluciones para mitigar el dolor.

El diseñador! Él nos salvará! Qué? Pues el especialista de UX!

(O ella, claro)

No. El/la diseñador(a) no está aquí para eso. El maquetador tampoco, por cierto. Su trabajo aunque claramente tiene que ver con el Frontend, está muy lejos de solucionar los problemas de arquitectura. No estamos hablando del aspecto visual de la aplicación. Y no, tampoco hablamos de la experiencia de usuario. Ambos temas son importantes, pero no son de lo que hablamos.

El problema que tratamos no es el del aspecto final de la aplicación, sino el de la organización del código en la parte de Frontend. Algo que, en muchos sitios, ni siquiera se plantea. Y aquí es donde está la raíz de todo el asunto.

Arquitectura de Frontend

Ha llegado el momento, tras una ya razonable experiencia comunitaria en el desarrollo de aplicaciones web, de madurar. Actitudes como las descritas, que describen las tecnologías de Frontend como inferiores de algún modo, son estúpidamente inmaduras (3). No, Javascript no es intrínsecamente malo ni feo. CSS no es aleatorio ni caprichoso. HTML no es algo místico y oscuro. Tampoco es cierto que el Frontend sea un detalle que se hace luego en un momento. El problema es que tú no te has molestado en aprenderlo ni en dedicarle el tiempo que sí le dedicas a la parte de servidor.

En servidor en estos años hemos ido aprendiendo y destilando técnicas y estructuras hasta llegar a soluciones razonables, estructuramos el código en capas, aplicamos patrones de diseño, usamos frameworks basados en Model2 (MVC para los que no les importe la diferencia), Inyección de Dependencias o lo que más nos guste, y sobretodo tenemos una serie de personas que analizan las funcionalidades y las arquitecturas a utilizar e implementar. En Frontend "pues se hace un Javascript y ya está". En Frontend dejamos que el código crezca de forma orgánica, o como mucho creamos una Guía de Estilo con unas pocas buenas prácticas y con eso esperamos que todo vaya bien. O peor aún: cogemos la arquitectura de Backend y se la encajamos como sea al Frontend.

Los arquitectos necesitan entender que Frontend también es un problema a resolver y que es uno distinto. Hay que dedicarle su propio tiempo de análisis, de diseño de arquitectura, de aprendizaje. No son admisibles las continuas quejas contra algo a lo que no se le ha dedicado el tiempo ni el esfuerzo que sí le dedicamos al resto. Es necesario crear una conciencia clara al respecto si queremos mejorar la calidad de las aplicaciones web.

Notas: En el contexto de este artículo... (1) desarrollador es el nombre genérico dado a cualquier persona que trabaja en desarrollo de software. (2) arquitecto es el nombre genérico dado a cualquier persona que toma decisiones sobre la estructura y arquitectura del software. (3) estúpido es el nombre genérico dado a cualquier persona que se sienta ofendido porque alguien en internet describa una actitud suya como estúpidamente inmadura.