Prólogo
Oficina. Interior. Día. Un momento cualquiera en el pasado.
Un front-end sujeta un machete entre los dientes, aprieta fuerte su mandíbula y siente cómo el sudor le recorre las mejillas. Titubea. Resopla. Finalmente, se adentra en la espesa jungla de código del proyecto con la esperanza de salir vivo de allí y poder commitear.
Oficina. Interior. Día. Presente.
Recién nombrado portador de la llama del buen front-end, tengo como obsesión que mi código (HTML, CSS y JS) sea un espacio ordenado, limpio, flexible, escalable e inteligible. Que haya que entrar quitándose los zapatos para no manchar. Para ello, en Kaleidos estamos aplicando una estructura de desarrollo en front que, mediante la combinación de las posibilidades de Gulp, Jade, Sass/LESS, y Frameworks MVC JS (Angular, mainly) permite de algún modo modularizar de una forma aceptable el código.
Web Components
Pero, curiosamente, al mismo tiempo que esa necesidad de orden y estructura se convierte en una exigencia para considerar un buen desarrollo, la W3C está trabajando sobre el estándar de los Web Components. Si bien todavía son un Draft, ya sabemos que su objetivo es:
- Crear tags personalizados de HTML que se van a compartir como cajas opacas, contenedoras de HTML, CSS y JS encapsuladas de modo que por defecto no van a interactuar con el resto de la página.
- Estos elementos pueden extender otros elementos o formar parte de ellos de forma anidada
- Dividen tu aplicación en elementos independientes, los cuales cumplen cada uno una funcionalidad y son estructuralmente sencillos (Shadow DOM)
- Interactuarán entre ellos para que varias funcionalidades definan un comportamiento.
Si después de leer esto no te has convencido de aprender más sobre Web Components probablemente no debas seguir leyendo, porque ahora lo vamos a retorcer un poco.
Si quieres aprender más aquí tienes material para rato.
Polymer
Sí, has acertado, los Web Components todavía no están soportados en todos los navegadores. Y no es un estándar, así que casi podríamos decir que en ninguno. Por eso Mozilla con X-Tags y Google con Polymer (entre otros) nos echan una mano para poder trabajar con sus navegadores y el posible futuro estándar. Polymer, en este caso, va un paso más allá que Mozilla en sus features de lo que algún día (espero) será el estándar (No he probado Bosonic). Y ya sabemos que en Kaleidos nos va el riesgo, la iocaína y las jornadas de 16h al día durante la Piweek, así que eché en la máquina de café un ristretto y me preparé, lunes y otra vez machete en mandíbula, sudor en frente, para atravesar la documentación de Polymer.
Algunas conclusiones de su uso:
- La creación declarativa de Web components, lo intuitivos que son y el maravilloso data-binding que hace que el trabajo sea sencillo. Polymer te da un trabajo hecho que es de agradecer. Mucho.
- La documentación de Polymer está pensada para leer de forma progresiva, no para consultar durante el desarrollo. Y, señores de Google, Polymer no es un cuento de “Teo maqueta”. Queremos documentación ordenada y de rápido acceso.
¿Y a todo esto, lo de la Mangosta?
Mangosta es el nombre que le he dado al proyecto con la mejor BSO del mundo cuyo objetivo era replicar esa estructura de front que se componía de:
- Gulp, como task manager.
- Jade, para crear los templates de HTML.
- Sass, como pre-procesador de CSS.
- SCSS linter para detectar errores de estilo en código. (además, made in Kaleidos)
- CSS linter para detectar errores de sintáxis en el CSS procesado,
- Javascript puro, porque lo hipster ahora es no usar jQuery (y por que no lo necesitaba, vaya).
Y aquí va mi primer error: la estructura clásica de desarrollo front no tiene nada que ver con los web components dado que estos forman un nuevo paradigma estructural donde cambia lo general por lo modular. Donde cada componente requiere, y sólo requiere, las mínimas dependencias necesarias para fucionar de forma independiente. Ese pequeño lío al principio (¡Oh no, no puedo usar mi DIY-front-end-framework habitual!) pasó a ser delicia en cuanto compiló mi cerebro.
ΠWEEK Movie Finder
Vale, vamos a aplicar todo este tostón. Shut up and show me the code. ΠWEEK Movie Finder es la forma que se me ocurrió para crear componentes y probar todo aquello que me ofrece Polymer leyendo de un API externa de _The Movie DB _y, con un poquito de dulce olor a ajax y el anterior citado data-binding, la app sonaba como una referencia para vuestros domingos de sofá y resaca. Un buscador de películas por género, década y nota media de los usuarios. A continuación veréis una captura de pantalla del proyecto (lo siento, diseñadores visuales, mi objetivo no era la belleza externa)
Y aquí una deconstrucción en los diferentes web components que tiene el proyecto (las lineas rojas):
Conclusiones o qué les contaré a mis nietos
Los Web Components son lo que un desarrollador de front avanzado debería anhelar de forma natural tras un tiempo de experiencia, sobre todo con la aparición de librerías de preprocesado de CSS, templating de HTML y Frameworks MVC que permiten una organización efectiva. Además, encajan con la moda-necesidad establecida en los últimos años por los referentes en el desarrollo front, que han apostado de forma masiva por establecer paradigmas de desarrollo modular.
Los Web Components pueden tener un problema en su aceptación masiva ya que van a exigir un cambio de mentalidad. No grave, pero notable, a lo que el desarrollador continuamente _deprecated _no va a saber adaptarse. Obviamente, dependerá de que los principales frameworks (Bootstrap, Foundation…etc.) adapten este método y establezcan workflows de trabajo asumibles. Los WebComponents no son tan accesibles como los preprocesadores, sin duda.
Con todas las dificultades de aprendizaje en una semana intensa (partiendo de cero y sin referente al que preguntar), *los Web Components son, sin duda, mi elección de desarrollo a medio plazo. *Te esperamos, Angular 2.0