Our Blog

Foundation for Apps (FFA, para abreviar ) es un framework frontend relativamente nuevo y muy novedoso, aunque visualmente puede parecerse bastante a su predecesor Foundation for Sites, por dentro es una bestia completamente distinta. FFA utiliza los novedosos flexbox en lugar de los ya tradicionales grids CSS, y además se integra completamente con Angular.js

En CianCoders hemos estado usándolo en algunos proyectos recientes, suficiente para formarnos muchas opiniones al respecto, muchas muy buenas… otras no tanto. En este post hago una crítica desde el punto de vista del desarrollador, y doy algunos tips para trabajar mejor usando FFA.

Lo bueno

FFA ha sido concebido para generar apps web muy rápidamente, maquetarlas, estilizarlas, y darle cierta funcionalidad casi al instante. Podríamos decir que sus ventajas mas importantes serían:

  • Instalación rápida y fácil sobre nodejs usando npm
  • Es muy personalizable al usar SASS para darle estilo
  • Flexbox, finalmente un framework completamente enfocado en esta novedosa especificación
  • Motion UI, un conjunto de fluídas animaciones en CSS3 que le dan vida a la aplicación
  • Incluye un set de directivas preestablecidas que hacen muy fácil generar funcionalidad sin tener que crear código

Todas esas características hacen que el trabajo inicial de maquetar una app se agilice bastante y se pueda tener las interfaces listas sin tener casi que crear código, aunque esa es una característica que es buena y mala al mismo tiempo.

 

Lo malo

FFA tiene una fuerte base en hacer las cosas fáciles para no programadores, ha sido diseñado mas para facilitar las cosas al diseñador/maquetador, que enfocado en ser un buen punto de partida para una app compleja desde el punto de vista técnico o de desarrollo, los peores puntos serían:

  • Falta de una estructura base para comenzar a agregar código de forma ordenada. Básicamente todo lo tendrías que agregar en el mismo fichero/directorio, lo que es muy malo para la escalabilidad de una app.
  • Falta de documentación técnica. En muchas ocasiones te quedas con la incógnita de cómo o dónde debes ver para modificar alguna funcionalidad o el porqué las cosas no funcionan como deberían
  • La constante alusión a agregar funcionalidad desde la plantilla no hace mas que complicar el trabajo del desarrollador, la mayoría de esas cosas no debería escribirse en la plantilla, o al menos deberían mostrar mas ejemplos de código.

 

Consejos para desarrolladores

A la larga trabajar con cualquier framework no es agradable, siempre se vuelve molesto cuando llegas al punto donde tienes que saltar de tu propio código a modificar o parchear el código del framework para que las cosas funcionen como deberían. Para hacer mas fáciles esos momentos, he reunido algunos de los problemas con los que me he topado y sus soluciones, ordenados a manera de lista de cosas por hacer antes de comenzar a escribir código.

1. Reordenar los directorios

Todo código debe tener un orden lógico, y eso es una ley que debe comenzar desde los directorios. Luego de instalar todo el código y plantillas va dentro de la carpeta client/ el código para Angular.js queda en client/assets/js/app.js, casi sin oportunidad de separar nada:

FA1

Mi estructura preferida de directorios no se divide en js, sccs, etc. sino que agrupa funciones, por ejemplo para una app que gestiona usuarios y empleados:

FA2

Para que esto funcione es necesario editar el archivo gulpfile.js para indicar que es necesario revisar cambios en esos directorios y agregarlos al código de la aplicación, hay que ubicar la parte que dice:

 // These files are for your app's JavaScript
 appJS: [
     'client/assets/js/app.js'
 ]

y cambiarla por esto:

// These files are for your app's JavaScript
 appJS: [
 'client/assets/js/app.js',
 'client/app/**/*.js'
 ]

De esta forma “compilamos” todos los archivos .js de nuestro nueva estructura de directorios.

Para las plantillas no he necesitado hasta el momento organizarlas, supongo que no es tarea fácil porque el ruteo se hace a partir de ellas. Es un tema que tengo por investigar.

2. Especificar el puerto para LiveReload

LiveReload es la funcionalidad que permite recargar el navegador automáticamente luego de hacer algún cambio, esto funciona por medio de una conexión a través de websockets.

No es un problema dejar eso como está, pero personalmente he tenido problemas para redireccionar el puerto default al hacer debug remoto con crhome, así que el puerto para el websocket lo cambio al 8081, hay que ubircar el servidor de gulp, siempre en gulpfile.js:

// Starts a test server, which you can view at http://localhost:8080
gulp.task('server', ['build'], function() {
 gulp.src('./build')
 .pipe($.webserver({
 port: 8080,
 host: 'localhost',
 fallback: 'index.html',
 livereload: true,
 open: true
 }))
 ;
});

y dejarlo así (agregar el objeto livereload):

// Starts a test server, which you can view at http://localhost:8080
gulp.task('server', ['build'], function() {
 gulp.src('./build')
 .pipe($.webserver({
 port: 8080,
 host: 'localhost',
 fallback: 'index.html',
 livereload: {
 enable: true,
 port: 8081
 },
 open: true
 }))
 ;
});

4. Integrar el Backend

Para empezar si necesitas comunicarte con un backend mi mejor consejo es que sea a través de un api REST. Personalmente uso siempre Django y djangorestframework para escribir el backend, siempre colocando el api dentro de la url /api/.

Aquí surge un problema, el frontend debe comunicarse con el backend mientras se desarrolla la app, como Django levanta el servidor de desarrollo en el puerto 8000, y FFA inicia siempre en el puerto 8080 no podemos simplemente hacer solicitudes directas desde el frontend hacia el backend.

Una forma de integrar los frameworks en desarrollo y que todo siga funcionando igual en producción es unificar todo bajo un mismo servidor, ya sea que Django sirva a FFA o viceversa. Sin embargo por experiencia sé que no es fácil hacer que cualquier framework frontend funcione muy bien servido desde Django.

La mejor solución es servir todo desde FFA aprovechando que nuestro único punto de comunicación con el backend es la url /api/ (otra ventaja de REST) haciendo que gulp funcione como un proxy sólo para esa url. En gulpfile.js:

// Starts a test server, which you can view at http://localhost:8080
gulp.task('server', ['build'], function() {
 gulp.src('./build')
 .pipe($.webserver({
 port: 8080,
 host: 'localhost',
 fallback: 'index.html',
 livereload: {
 enable: true,
 port: 8181
 },
 open: true,
 // django app
 proxies: [{
 source: '/api',
 target: 'http://localhost:8000/api'
 }]
 }))
 ;
});

Conclusión

FFA es un framework que aprovecha la tecnología actual y que logra ser estable aunque sigue en constante desarrollo, si no te molesta tener que lidiar con algunos problemas o la falta de documentación que normalmente se encuentra en las nuevas ideas, es una herramienta de buena calidad para desarrollar interfaces frontend rápidamente. Para un desarrollador puede llegar a ser molesto no tener el control que se desearía sobre el código, pero afortunadamente eso se puede mejorar como se ha descrito en este post.

Comments ( 0 )

    Leave A Comment

    Your email address will not be published. Required fields are marked *