Antes de nada, está claro que si vas a hacer un portal, un foro, o una red social tienes que utilizar tecnología web, pero si vas a hacer una aplicación de gestión, el photoshop, o una herramienta para grabar DVDs, las aplicaciones de escritorio, por ahora, son mejores.

En el año 2000, hacíamos aplicaciones web en ASP, desarrollé un framework, que permitía hacer aplicaciones en un tiempo casi igual que aplicaciones tradicionales, pero claro, con la limitaciones que teníamos entonces con los browsers, no obstante generamos algo similar a AJAX, y pudimos añadir bastante interación entre browser y servidor.

Por entonces, la empresa en el que trabajaba, encargo a una gran consultora que estudiara cual era el futuro de la tecnología web, y esa gran consultora dicidió que había que migrar a Java. Así que la empresa, empezó a mirar todo a JSP, por entonces dejé la empresa, no me apetecía abandonar mi know-how en ASP y tener que empezar desde el principio.

En el 2005 volví a la empresa, a incorporarme en uno de esos proyectos Java, durante esos años, habían migrado muchas aplicaciones a JSP, despúes las habían vuelto a migrar a Servlets, después a Webmacro y ahora volvían a cambiar para utilizar Struts.

En el 2007, nos pidieron que analizaramos las distintas tecnologías disponibles, por que se proponían a dar el gran paso y migrar una aplicación de más de 1000 pantallas, con un coste de unos 10 millones de euros. Durante el análisis, se propuso esperar a la nueva versión de Struts, a utilizar JSF, incluso volver a ASP.

A mi, me pareción una aberración ir a la “moda”, supongo que a día de hoy se están planteando utilizar AJAX, o incluso Ruby. Cuando hablamos de algo “tan grande” no podemos estar dependiendo de tecnologías que no están consolidadas.

Si nos fijamos como lo hacen los grandes como Oracle, SAP, etc… ellos tienen su propia tecnología, no dependen de la moda, en lugar de dedicar tiempo a programar en web, con struts, o con JSF, lo que hacen es definir su interfaz en un formato propio, y luego lo presentan en Web o en aplicación tradicional, o como quieran.

En software libre existe algo parecido, es llama XUL, lo utiliza por ejemplo Google en su software AdWords Editor.

Con la especificación de interfaz, independiente de la tecnología, nos aseguramos una evolución constante de nuestro software. No tenemos ni idea, de que estará de moda dentro de 3 años, lo mismo, AJAX desaparece……

Existen muchas aplicaciones OpenSource que utilizan tecnologías similares como OpenBrave, OpenErp, etc..

Así, que con este conocimiento, al empezar un proyecto, tengo varias alternativas:

• Desarrollo en Web, sabiendo que estar a la moda tiene un coste extremadamente alto.
• Desarrollo en XUL o tecnología propia, que tiene un coste alto inicial en desarrollo de frameworks, herramientas, etc…
• Desarrollo en Escritorio, que tiene un coste muy bajo, que la tecnología ha madurado ya, y que no se esperan cambios radicales en los próximos años.

He optado por hacer aplicaciones de Escritorio, por tiempo y coste, en otra situación hubiera elegido XUL, pero nunca un desarrollo web.

Como ejemplo siempre pongo Google, tiende a desarrollar todo en Web, sin embargo, cuando hay dinero por en medio y el usuario lo pide, hace una aplicación de escritorio, como el editar de anuncios AdWords Editor.

Seamos prácticos, las aplicaciones web tardarán algunos años más en equiparse a las de escritorio, pero además, no sólo se tienen que equiparar, hay que equiparar también la facilidad de desarrollo en web.

¿Por qué son mejores las aplicaciones de Escritorio?

Estas son mis razones, está claro que se pueden solucionar de una forma u otra, pero, siguen siendo un grave problema.

1. Botón Atrás. Parece una tontería, pero no lo es, el botón atrás del explorador es uno de los mayores enemigos de las aplicaciones web, generando multitud de errores diferente, por que, en algunos casos, puede que vaya a la pantalla anterior, pero en otros casos, acabamos con registros duplicados, formularios que se vacían sólos, etc…

2. Tecla Borrar. La tecla borrar, en cualquier navegador, es volver atrás, sabéis lo que fastidia estar en medio de un formulario y darle a borrar y que se vaya a la pantalla anterior y tener que empezar de nuevo????

3. La sesión. Te llaman por teléfono, vuelves a tu teclado, y cuando le das a aceptar… pummmm La sesión a expirado. Ha empezar de nuevo o… no se sabe por donde…

4. Múltiples Ventanas. Salvo contadas excepciones, como WordPress, o alguno más, la mayoría de las aplicaciones web sólo son capaces de hacer una sola cosa a la vez. Me explico, estoy escribiendo este artículo, y al mismo tiempo puedo dar de alta Categorías, para hacer otra cosa, tendría que abrir una nueva ventana/pestña!!!! En las aplicaciones de Escritorio puedes hacer muchas cosas al mismo tiempo.

5. Acceso a las recursos del sistema. Si tienes un programa que necesita dos impresoras diferentes, según el tipo de documento, con una aplicación web la hemos liado. No se puede, tenemos que estar cambiando de impresora. Es un ejemplo, pero es la realidad, el acceso a los recursos locales es muy limitado.

6. El browser se muere…. Cuando mezclamos una aplicación web en el mismo browser, con el facebook, el último video de youtube, radio online, etc.. llega un momento en que se muere y crash… al final me he tenido que instalar 2 browsers, una para aplicaciones y otro que utilizo para cosas que pueden hacer el browser morir. Ya sé que es culpa del browser, pero…

7. AJAX. Es bueno, es muy bueno, siempre que se utilice bien, pero utilizarlo bien, tiene un coste altísimo, y pocas personas son capaces de hacer aplicaciones COMPATIBLES en AJAX que funcionen bien.

8. Compatibilidad. Magento es uno de los sistemas de comercio electrónico de nueva generación más famosos, pues bien, no me funciona en mi browser, es incompatible.

9. Favoritos e Historial. No hay cosa más peligrosa que un usuario acceda a una página directamente de una aplicación, sin pasar por los pasos necesarios. He visto usuarios que se guardaban en el favorito patallas que requerían pasar por un paso previo, y al acceder directamente, montaba unos líos increíbles.

10. Ancho de Banda. Si, si, ancho de bando. Una aplicación web tiene que transmitir, la pantalla, las librerías de AJAX, la hoja de estilo, las imágenes, y los datos!!! mientras que una aplicación de escritorio, sólo transmite los datos.

1. Cache, cache y mas cache

Es totalmente innecesario acceder a los mismos datos en la base de datos una y otra vez, es mucho mejor, guardar estos datos en memoria o en disco, y utilizarlos en las sucesivas llamadas.

Además de este tipo de datos, están los parámetros, las preferencias de usuarios, etc…

El uso de cache, mejora radicalmente la velocidad de una aplicación.

2. Arranque Rápido.

Esta es mi técnica preferida, ideal para redes lentas. No es fácil de implementar y requiere un poco de lógica. Se recoge estadística de las tablas y recursos más usados por la aplicación cuando arranca, por ejemplo, podemos tener una aplicación que normalmente abre un formulario y que tiene una lista desplegable con provincias.

Basándonos en las estadísticas, hacemos que arranque en paralelo y proceso que precarge los datos más usado, de forma que cuando el usuario acceda, no tiene que esperar que lleguen los datos.

3. Optimización de Base de Datos

No voy a detallar todas las técnicas, pues hay muchas, pero las principales son optimización de índices, minimizar los accesos a bases de datos, desnormalización cuando es necesario, estudio de planes de ejecución de consultas, etc..

4. Escalabilidad

Quizás, la parte más complicada a la hora de desarrollar una aplicación. Lo primero es ¿como sabemos si es escalable? Existen herramientas que simulan la carga de trabajo de miles de usuairos, es un buen punto de partida.

Pero ¿como lo hacemos más escalable? Existen muchas técnicas, pero la más sencilla y útil es diseñar los sistemas para que se puedan ejecutar en paralelo, no diseñar un proceso central que lo hace todo en el servidor, es mejor diseñar, pequeños procesos de trabajo que se pueden ejecutar en paralelo.

Ahora estamos probando la ejecución distribuida de los procesos del servidor, de forma, que todos los ordenadores de la oficina, participan en el proceso global, aportanto parte de su CPU.

5. Sensación y percepción

Un día llegó a mis manos un documento de Microsoft muy curioso, sobre la percepción que tiene el usuario de la velocidad de un programa, y me pareció muy interesante. La típica barra de progreso que tenía Windows al principio al iniciar, fue sustituida por una barra que se movía a toda prisa y daba varias vueltas. La percepción del usuario es importante, y tenemos que cuidar todos los tiempos muertos de la aplicación, utilizar iconos con reloj, animaciones, etc….