Enfoques para escoger un framework Javascript en Móviles

En este post veremos los dos grandes enfoques para escoger un framework base de trabajo. Entre otros se intentará responder a estas preguntas:

Hay realmente que usar un framework si ya estamos usando cosas como WAC o phoneGap (se explicaran en próximos post)?

Que es mejor Sencha, JQTouch, Jquery Mobile, Jquery, mootols, …?

¿Qué consideraciones debemos hacer para elegir uno o el otro?

¿Cómo podemos probar los diferentes frameworks?

Vamos a intentar ver todo esto!

Algunas respuestas que debemos tener claras

¿Porqué desarrollamos aplicaciones de escritorio con tecnología web?

– Porque queremos que una misma aplicación sea multi-dispositivo, e independiente del dispositivo lo posible, como ocurre con JAVA, o al menos, como ocurre con el “C ANSI” en diferentes plataformas.

– Porque conocemos (o estamos aprendiendo) la tecnología web y queremos podemos aprovechar los conocimientos que ya tenemos para producir.

¿Qué objetivos tenemos cuando queremos hacer una aplicación exclusivamente para dispositivos móviles (independientemente de si usamos el hardware del dispositivo o no)?

– Que nuestras aplicaciones se publiquen en un canal de ventas masivo (aunque el producto final tenga coste 0 €). Una aplicación en una web no está en cada escaparate masivo, y puede quedar aislada, sin público. Para ello usamos el ecosistema WAC ole PhoneGap (que se verán más adelante).

¿Cuál es el objetivo no funcionales más importante si desarrollamos aplicaciones para móvil con tecnología web?

– Que se parezcan tanto como puedan a una aplicación nativa de escritorio.

¿De qué depende que se parezcan tanto como puedan a una aplicación nativa?

– De poder usar los componentes del dispositivo si hace falta. (Con PhoneGap o WAC).

– De aprovechar todas las novedades HTML5:

Es decir, que haya geoposicionada web y que la aplicación pueda correr Offline.

– Que la UX (User Experience) sea de escritorio:

En principio un usuario de aplicaciones de escritorio espera encontrar una aplicación de escritorio. En el fondo lo estamos “engañando”. La aplicación correrá bajo un navegador web, pero él no lo debe notar. Y eso cuesta, y yo diría que es imposible. De hecho… hasta qué punto deben vestirse todas las aplicaciones de escritorio todas igual? Quizás no es un punto en contra sino un punto a favor.

– Rendimiento:

En una aplicación de escritorio nunca se espera que se cargue una página, como mucho, espera que se cargue de vez en cuando información dentro algún elemento. El rendimiento es la clave. Deben generarse las mínimas conexiones con el servidor.

Puede encontrar más información en un post de Quirksmode que es del 2009, pero las características que se buscaban son las mismas. La diferencia entre el 2009 y ahora, es que el rendimiento ha mejorado muchísimo.

Sobre los frameworks

¿Qué peso le damos a javascript (JS) dentro de nuestra aplicación? En general, para una sitio web (site), el JS tiene un peso no superior al 50%, básicamente es html y CSS3. En aplicaciones más RIA (Rich Internet Application) el peso de Javascript aumenta (google maps por ejemplo). Incluso hay aplicaciones donde el peso del JS es del 99%: aplicaciones de una sola página, cargas con AJAX y componentes definidos con html incrustado en el JS.

Pues bien, en general para elegir el framework una de las consideraciones principales es el peso que tiene el HTML + CSS en la página o el peso que tiene el JS.

Actualmente se usan los siguientes grandes enfoques para construir aplicaciones de escritorio con JS:

– Un framework JS principal que hace todo el trabajo posible ( poco control del programador de la programación de “bajo nivel”)

Un santo grial que permita tener una librería de componentes y opciones, y el desarrollador es un usuario del framework más que del html, del css e incluso del JS. Ya podéis pensar cuáles son a nivel conceptual los pros y contras de esta opción. Los grandes frameworks que se usan con diferentes filosofías son:

SenchaTouch: Sencha Touch es un framework que se basa en aplicaciones de una sola página html (de hecho, todas las de móvil deberían ser así). Y, lo que es más espectacular, el framework lo hace todo! Que queremos un componente en una página: hacemos un llamamiento al framework. Que queremos cargar los datos en un componente: hacemos un llamamiento al componente. Etc … No hay html, ya que todo el html está incrustado en el JS del componente y se mete dinámicamente.

JQueryMobile: JQuery es una librería con muchas funcionalidades pero le da más peso al html. La filosofía es crear un HTML5 con una estructura establecida para cada componente (página, visor, etc ..) y automáticamente se le asocia una lógica con la librería. Por tanto, podemos trabajar con el html y el Css de forma amigable y la curva de aprendizaje es menor. Pero, la UX (user eXperince) es peor que en el primero.

Puede encontrar más información y muy útil en este enlace de Mark Power.

– Framework que sólo me ayude las Vistas o Interfaz de Usuario (más control, mas trabajo)

Si sólo queremos un framework para la Interfaz gráfica y nosotros queremos encargarnos del resto, este enfoque es el nuestro. Sin embargo, estamos hablando de encargar al framework principal TODA la interfaz gráfica.

Aquí la opción más recomendada es JQTouch. Podemos ver cómo programamos aplicaciones para iPhone con JQTouch con este tutorial (que es un excelente libro).

– Soy Juan Palomo, Yo lo programo, yo me lo como. (Control total)

En general esta opción sería para los que quieren un rendimiento máximo, una UX única. Aquí hay dos puntos de vista diferentes:

– No se usa ningún framework en particular. Si existe la necesidad de usar uno, entonces se analiza y se usa en función del rendimiento.

– Se usa una aproximación MVC (Modelo-Vista-Controlador) con un framework de tamaño mínimo y rendimiento bueno. Normalmente cuando la aplicación tiene bastantes páginas y componentes a orquestar, no se puede usar el punto anterior y se opta por esta. Sin embargo, hay quien se construye su propio MVC.

De este última opción hablaremos en la siguiente unidad, ya que da para un tema en sí, y sobre todo para un concepto: el patrón arquitectónico Modelo Vista Controlador en el lado del cliente, implementado con JS.

Roman Roset, ALGOS. Recerca en Dolor

Universitat Rovira i Virgili, Tarragona