El futuro de Symfony

La tercera edición de desymfony volvió el pasado 30 de junio a Castellón, cuidad que le vio nacer.

Lo hizo con el reto de cumplir con las altas expectativas de los asistentes, entre los que nos encontrábamos muchos de los desarrolladores PHP de Irontec.

El stock out de las entradas al evento era previsible dada la buena salud del framework y el gran nivel mostrado en las conferencias del año pasado. Conferencias entre las que personalmente destacaría:

• CQRS y Event Sourcing en aplicaciones Symfony
• Sobreescritura y extensión de validaciones, formularios y entidades
• Refactorizando PcComponentes.com con Symfony
• Buenas prácticas para crear bundles de alta calidad

La primera conferencia, `Symfony Flex y el futuro de Symfony`, corrió a cargo de Javier Eguiluz: miembro del «Core Team» de Symfony, creador de symfony.es y autor del libro Desarrollo web ágil con Symfony2. Es además uno de los organizadores del evento y vitoriano 🙂

Conocer el roadmap de symfony de la mano de un insider gusta y precisamente de esto trató la conferencia.

El reto

`El cambio tecnológico se está acelerando`: Así rezaba una de las diapositivas mostradas. La forma en la que los desarrolladores trabajamos ha cambiado mucho en pocos años:

• Las herramientas de gestión de dependencias, independientemente del lenguaje, han demostrado su valía y madurez convenciendo hasta a los más escépticos. Hemos dejado de implementar mucho código propio en favor de librerias existentes guiados por el feedback de la comunidad. No es que antes no hiciésemos uso de software de terceros, pero por lo general, nos limitábamos a frameworks y librerías con nombre propio (Y eso por no echar la vista aún más atrás…).
• El despertar de javascript: Lenguaje de moda, ya sea en backend (node) o en navegadores, cuando no en ambos. JS está adquiriendo responsabilidades que dudo que ninguno de sus padres supiera anticipar cuando implementaba el alert. jQuery fue el amo y señor por al menos ¿Un lustro? No parece que esto vaya repetirse a corto plazo; noticias sobre nuevas librerías, patrones de diseño o frameworks inundarán tu feed si te despistas.

Con los años symfony se ha reconvertido progresivamente en un framework de «bajo nivel». Brinda herramientas más que aportar soluciones cerradas/completas y da libertad al programador. Con la mirada puesta en seguir siendo relevante, ha evolucionado de la mano con la industria y no ha sido pequeño el esfuerzo por la integración con los «grandes». Reinventar la rueda intentado hacerlo mejor que el resto hubiese sido una opción no hace tanto. Hoy optar por doctrine o monolog es el camino.

La cuarta versión de Symfony, prevista para Noviembre, no hará más que profundizar en ese aspecto.

 

Adios Assetic, hola Webpack Encore

Assetic, el componente para la gestión de hojas de estilos y ficheros javascript, no se incluía en `Symfony SE` desde la v2.8, pero no había reemplazo oficial hasta ahora.

Webpack encore es una capa de abstracción que simplifica la configuración de webpack. Programado en javascript, soporta todo lo que el frontend de una aplicación moderna pueda requerir: Pre/Post procesado, source maps, combinar, minificar, etc. Obviamente se integra a la perfección con symfony pero no es requisito para su uso.

Del anuncio oficial de encore podemos extraer la siguiente cita que refleja a la perfección la filosofía:

When you use Symfony, we want to make it simple to leverage the best tools from beginning to end. That’s why, for assets, Symfony 2.0 came with Assetic: a pure PHP library. In 2011, this made sense. In 2017, life is much different.

Now, the best-practice tools for processing assets are written in Node.js. And Webpack is a clear leader. Since we want to recommend the highest quality tools, we recommend Webpack.

Aún no tenemos la primera versión estable (v1.0) pero nada impide que puedas hacer tus primeras pruebas con encore.

Symfony 4

Del mismo modo que la v2.x trajo componentes desacoplados y la v3 introdujo el microkernel, symfony 4 vendrá con cambios importantes:

• `Adios al monolito`: Hasta ahora se buscaba que, de base, symfony fuese capaz de aportar todo lo necesario independientemente del tipo de aplicación a desarrollar: web, api, consola, etc. No en vano, la edición estándar de symfony consta de más de 40 componentes, 15 librerías y 11 bundles. Este enfoque ha muerto. A partir de ahora tendremos micro aplicaciones base a las que añadir aquello que requiramos. Tanto es así que la base de symfony 4 tiene un 70% menos de líneas de código que 3.3.
• Nueva estructura de directorios: Sin cambios revolucionarios pero encontrarás varios directorios reubicados o renombrados. También se centralizan los contenidos de front: Assets, templates, etc. 
• `No más bundles privados`: La separación modular del código de aplicación se hará exclusivamente vía namespaces de PHP. El concepto bundle se conserva exclusivamente para software de terceros instalado vía composer.
• parameters.yml desaparece para apostar por variables de entorno.

Symfony Flex

Symfony Flex será la herramienta por defecto para gestionar las aplicaciones Symfony 4. Se trata de un plugin de composer que facilita la instalación de bundles de terceros. Hasta ahora instalar un bundle requería de los siguientes pasos:

1. Ejecutar composer require nombre/bundle
2. Registralo en AppKernel
3. Configurar el bundle y, en ocasiones, sus rutas

De igual modo, en la desinstalación era necesario ir deshaciendo tus pasos manualmente. Flex promete reducirlo a composer require/remove nombre/bundle. Gracias a «recetas» definidas por la propia comunidad, flex automatiza la (des)activación del bundle, define sus variables y crea un fichero de configuración inicial. Estas instrucciones están alojadas en dos repositorios bien diferenciados:

1. symfony/recipes es el repositorio oficial de recetas: cualquier aportación requerirá de la aprobación explicita del core team de symfony.
2. symfony/recipes-contrib será la versión poco «exigente» pero vendrá desactivado por defecto.

Flex es perfectamente ejecutable a partir de la versión 3.3 pero requiere de una estructura determinada de directorios que actualmente hay que cambiar manualmente.

Conclusiones

Symfony 3.0 fue una release aburrida, Symfony 4 no lo va a ser :).  Si este artículo te ha sabido a poco, symfony.es puede ser un buen siguiente paso. También puedes consultar la diapositivas de la conferencia, de las que se nutre este post, aquí.