He aquí la gran pregunta.

Respuesta corta: porque tenemos un Transtorno Obsesivo Compulsivo. De ahí el nombre del framework. Tocstrap. Ríete tú de Sterling Cooper.

Respuesta larga: porque nos hacía falta una herramienta front con la que afrontar nuestros proyectos, que nos hiciese más rápidos, autónomos y eficaces, y evitase malgastar tiempo en tareas repetitivas de un proyecto a otro. Y todo ello sin generar dependencias de terceras partes, o las mínimas posibles, manteniendo el máximo control sobre el código.

Es decir, un TOC de manual.

Home de Tocstrap
Sí, sí, van en serio, le hemos puesto ese nombre

Así que, con las suficientes referencias a nuestras espaldas que dan el ya maduro recorrido de Elemento115, y que nos permiten saber qué necesitamos como equipo y qué nos haría mejores, nos decidimos a comenzar nuestro propio framework de CSS y JavaScript.

La forma de abordarlo es sencilla: siguiendo las ideas del Atomic Design hemos creado una conjunto de componentes aislados entre sí que nos permiten afrontar de forma automática la creación de cualquier elemento que nos podamos encontrar en un proyecto, así como dotarle de comportamiento. Y todo ello documentado en unas guías de estilo dinámicas, accesibles a través de una URL propia, y que cargan los mismos ficheros que el resto del proyecto. De esta forma nos aseguramos de la autoactualización de la guía de estilo, ya que al modificar el componente del proyecto se modifica automáticamente su homólogo en la guía de estilo.

A todo ello hay que añadir un sistema de grid, basado en el de Bootstrap, que permite a los desarrolladores una buena dosis de autonomía al crear plantillas, sin tener que depender del departamento de Front-end. No nos hemos atrevido aún con el CSS Grid, pero sí con Flexbox, y en lugar de las 12 columnas habituales nos hemos ido hasta las 20, que da más margen para afinar y da divisiones enteras del 100%, y no números periódicos puros en los que uno no puede confiar. Otra vez el TOC.

Columnas del sistema de grid de Tocstrap
Nuestro grid en todo su esplendor

También hemos aportado las ventajas que da usar SASS y Gulp. Tenemos un fichero de settings que configuramos al inicio del proyecto y que nos permite establecer de forma cómoda y rápìda aspectos tan dispares como:

De este fichero beben todos los componentes del framework, así que si a mitad del proyecto el cliente quiere cambiar un rojo por un verde, tardamos unos 10″ en hacerlo (y 9″ son de abrir el fichero y arrancar el Gulp).

Aspecto del fichero de settings de SASS
Todas estas cosas podemos modificar fácilemente

El resto de elementos CSS del framework se reparten en módulos de SASS que agrupan aspectos similares, tales como layout, texts, forms… Desde la hoja de estilos principal cargamos dichos módulos, que junto al reset CSS y a los mixins de SASS, nos dejan en una posición de inicio estupenda para arrancar el proyecto con mucho tyrabajo ya hecho.

En cuanto al JavaScript, reunidas todas las funcionalidades en un único fichero y encapsuladas en objetos aislados entre sí, nos permite una inicialización muy sencilla basada en unas convenciones de sintaxis HTML para cada componente y una llamada al método init() correspondiente. No hay, por tanto, que preocuparse por el comportamiento: el framework hace el trabajo por ti.

Aspecto del fichero principal de JavaScript
El init() es nuestro amigo

Esto que hemos hecho no es más que el arranque del camino. Nos queda muchísimo por recorrer, muchas cosas que añadir, unas cuantas que modificar y más de una que eliminar. Tal vez cambiemos Gulp por Webpack o usemos ambos, puede que dejemos de lado jQuery por ES6, incorporaremos Grid CSS en cuanto podamos, y una lista interminable de cambios que ahora ni podemos intuir. Pero la idea básica, el esqueleto sobre el que construir, seguirá siendo el mismo: un único framework para gestionarlos a todos.