Últimamente tengo muchas conversaciones donde se hablan de aplicaciones SPA (Single Page Application) y en el momento de hablar de que librería me gusta más, siempre suele salir a la palestra Knockout y no puedo evitar poner cara de circunstancia, porque esta librería en concreto no me encaja en absoluto como SPA.
Parece ser que no queda muy claro cual su intención o que necesidad cubre. Por eso haré una pequeña comparación sobre diferentes librerías para poder despejar las dudas que se puedan tener sobre ellas.
Que es una aplicación SPA
Una aplicación ”Single Page Application” como bien indica su nombre, es aquella que tiene una pagina principal que se utiliza como contenedor de el resto de páginas. No necesita cargar completamente el documento, es capaz de separar las vistas de los datos e inyectar el contenido de las paginas o vistas en el contenedor principal. De esa manera puede controlar la carga, la navegación, el histórico, etc. Eso nos permite ofrecer una experiencia de usuario más rica y tener el control total de la interfaz de usuario desde el cliente.
Por eso una buena librería para hacer SPA tendría que darnos una solución completa a estas necesidades:
- Routing: Navegación e histórico.
- Datos: Tratamiento de datos con las llamadas AJAX
- DOM: interactuar con los objetos del documento.
- Mv* : Estructura del código y separando responsabilidades utilizando un patrón Modelo Vista …
-
- Data Binding: es importante que si separamos las vistas del modelo de datos, tengamos un mecanismo para que se comuniquen las dos partes de forma automática y tener un “Two-Way Data Bind” es una buena opción.
- Async: Para trabajar con procesos o llamadas a otros módulos lo mejor es utilizar asincrónica y utilizar Promises para facilitar esta tarea.
- DI: si utilizamos módulos AMD como componentes se tendría que poder hacer inyección de dependencias.
- Testing: esto ya es para nota
La Comparativa
Comparación de las principales librerías que se utilizan actualmente en el desarrollo Web:
|
Librerías |
Datos |
DOM |
Routing |
MV* |
DataBind |
DI |
Testing |
| KnockoutJs |
X |
X |
X |
MVVM |
✓ |
X |
X |
| AngularJs |
✓ |
JQlite |
✓ |
MVW |
✓ |
✓ |
✓ |
| Durandal |
✓ |
JQuery* |
✓ |
MVW |
KnockoutJs* |
Require* |
X |
| Backbone |
X |
X |
✓ |
MVC |
X |
X |
X |
* Tiene dependencia con esta librería para su funcionamiento.
- Knockout: Como se puede observar esta librería solo nos aporta una manera muy potente de enlazar nuestros datos con las vistas utilizando MVVM y utilizando Two-Way Data Bind. No tiene dependencias con otras librerías es 100% JavaScript y no abarca todo lo que necesita una aplicación SPA por si sola.
- Angular: Framework que abarca todo el desarrollo con JavaScript y nos evita depender de otras librerías. Además podemos hacer test unitarios de nuestro código.
- Durandal: Es una librería que se apoya en otras para poder cubrir todas las necesidades de una aplicación SPA.
- Knockout para el Data Binding,
- Require para la inyección de dependencias
- JQuery para el las llamadas AJAX e interactuar con el DOM.
- Backbone: Una librería muy liviana, más dirigida en estructurar nuestro código utilizando un patrón MVC que dar cobertura a una aplicación de tipo SPA.
Conclusión
Como se ha podido comprobar en esta comparación Knockout no se puede comparar con las librerías o frameworks SPA, porque solo tiene un objetivo. Que es enlazar nuestro datos con las vistas utilizando un patrón MVVM.
Para conseguir una experiencia SPA completa, tendríamos que combinar Knockout con otras librerías como hace DurandalJS.
Espero que esta reflexión en voz alta deje fuera de las conversaciones sobre SPA a la pobre Knockout 😉
