sproutcoreHeader

Elevando el nivel de JavaScript y de las aplicaciones web

Hace tiempo maté a Flash y comenté los interesantes Frameworks JavaScript que se estaban desarrollando. Hoy hablaremos de ellos y de alguna sorpresa más, con una clara mirada hacia el futuro de la programación en la web.

Primero, un poco de politiqueo.

Apple no se negó a dar soporte a Flash en iphone por simple cabezonería, en realidad tenían su propia alternativa para las aplicaciones RIA, y ésta era SproutCore.

No dudo que detrás de la idea de negarse a incluir Flash en iphone y ipad pudiese estar una acertada intención de seguir los estándares y apoyar el soporte nativo a través de HTML5… Pero lo cierto es que apoyar el Framework SproutCore parece encajar perfectamente en una estrategia multinivel.

  • Mac OS X para dispositivos como las Macs y MacBooks, con Cocoa como el interfaz de aplicaciones nativas.
  • IPhone OS, basado en Mac OS X, con Cocoa Touch para interfaces orientadas a dispositivos móviles.
  • SproutCore, para aplicaciones web “no nativas”  que funcionan tanto en Mac OS X, como en el iPhone, o en cualquier otro navegador del mercado (su alcance es total).

Esto, en mi opinión, es un plan a medio/largo plazo esquisitamente orquestado y estoy seguro de que según pase el tiempo se irá haciendo más y más patente la dominación de la manzana sobre todos los pueblos libres (¿todavía no tienes un iphone? cómprate uno).

Las aplicaciones web parecen ser el futuro, y meter bien la pezuña en el terreno es algo que Apple tenía que intentar, aunque tuviera que dejar fuera de combate a Flash por el camino. Después de todo, haber soportado a Flash en iphone habría sido una tontería, estratégicamente hablando.

En cualquier caso SproutCore parece una herramienta fantástica y con mucho futuro, y tener a Apple detrás no hace más que aportar solidez al proyecto.

[divider_padding]

Los nuevos frameworks JavaScript

Crear interfaces de respuesta rápida y de fácil mantenimiento para aplicaciones web no es para nada algo sencillo. El ecosistema web está todavía verde: La web fue concebida con un objetivo más básico, pero de alguna manera nos hemos ido dando cuenta de que el navegador web es el único punto en común entre un Mac, un PC, un móvil y un tablet, y que el uso de servicios online y del almacenamiento remoto evita la tiránica dependencia de nuestros archivos locales. Es decir: La Nube es el futuro.

Pero hete aquí que las infraestructuras de este mundo futurista son tercermundistas. Llevamos toda una vida programando para el escritorio con herramientas que ya son sólidas, pero trasladarlo a la web resulta complicado, puesto que el lenguaje que debe ayudarnos en esta tarea, JavaScript, que es soportado por todos los navegadores, es en su origen un humilde lenguaje de scripting enfocado a tareas sencillas, y a medida que aumenta la complejidad del proyecto todo se nos va de las manos.

JavaScript necesita una aproximación más seria, y es por eso que los principales Frameworks JavaScript de nueva generación vienen a dotarlo, entre otras cosas, del paradigma modelo vista controlador (MVC).

¿Qué es el MVC y por qué JavaScript lo necesita?

El modelo vista controlador viene a estructurar nuestro código en 3 capas:

  • El modelo: La estructura de datos de nuestra aplicación. (Podría ser la base de datos)
  • La vista: La parte visual, nuestra interfaz de usuario, lo que vendría a ser el frontend. (Podría corresponderse con el HTML)
  • El controlador: La tradicional lógica de negocio de nuestra aplicación; gestiona eventos y calcula resultados. (Operaciones JavaScript)

Se trata de una forma ordenada de hacer nuestro trabajo fácil y escalable.

¿Por qué JavaScrip lo necesita? Bueno, creo que está bastante claro, pero el que quiera profundizar y no tema el inglés puede leer más sobre el uso del MVC en javascript.

SproutCore

El mérito de Sproutcore es asilarte de los puntos más tediosos y conflictivos de la programación para el cliente. Si todo está correctamente bindeado la vista irá actualizándose a medida que los datos de nuestra aplicacicón cambien, sin necesidad de recorrer el DOM mil veces haciendo comprobaciones aquí y allá.

Lo que realmente me atrae de SproutCore es que usa JavaScript como lenguaje, de modo que no es necesario aprender otros lenguajes, al contrario que Cappuccino, que hace uso de Objetive-J o GWT que usa JAVA; aunque al final todo se traduzca a JavaScript, que es lo que entienden los navegadores (parece que tiene papeletas de convertirse en una especie de código máquina de los navegadores). Por otro lado parece un sistema muy versátil, proporcionándote una sólida base a partir de la cual tu proyecto pueda crecer lo que necesite; con Frameworks como GWT siento que me llevan de la mano y que de alguna manera eso me condiciona.

Con una explicación tan simple como la mía SproutCore no parece más especial que otros que pretenden lo mismo. Así pues, ¿Qué es y qué no es SproutCore? Como muchas tecnologías recientes de la web, se entienden mucho mejor con demos:

[divider_padding]

JavaScript en el servidor con Node.js

nodejs

Sin duda una tecnología con mucho futuro. Se trata de un entorno JavaScrip orientado a eventos de entra/salida (Permite leer y escribir en ficheros, en conexiones de red (sockets), en procesos del Sistema Operativo, etc.) de manera asíncrona, usando todo el poder del motor javascript V8 de Google. ¿Te ha quedado claro? Sigue leyendo…

Tradicionalmente los servidores web siguen la norma de 1 conexión = 1 proceso, de modo que cada petición se procesa en paralelo. Está comprobado que a partir de 10 000 conexiones concurrentes el rendimiento cae abruptamente en los tradicionales servidores Apache. Esto se vuelve especialmente delicado en conexiones keep-alive o Comet, en las cuales el servidor mantiene conexiones con un cliente que a menudo no hace nada la mayor parte del tiempo pero consume recursos igualmente.

Node.js soluciona este problema al tratarlo todo de manera asíncrona. En lugar de generar un nuevo hilo para cada conexión (y asignarle memoria), cada conexión dispara la ejecución de un evento.

No se trata de una simple solución de escalabilidad para sortear el problema de las C10K, sino que nos permite crear aplicaciones en tiempo real de manera muy sencilla a través de WebSocket.

No hay duda de que la web en tiempo real está cada vez más presente. Pensarás: “un momento, eso es AJAX”. Sí, el planteamiento clásico de AJAX es el de enviar peticiones asíncronas al servidor sin recargar la página, pero podemos ir más allá y pretender que sea el servidor el que envíe un mensaje al cliente sin éste pedirle nada (genial para un chat, por ejemplo). Para estas cosas Node.js parece el camino.

Tutoriales para empezar con Node.js:

Hosting gratuito con soporte para Node.js

[divider_padding]

Todo junto

todos

La idea de usar SproutCore para desarrollar el lado del cliente y Node.js en el servidor resulta muy atractiva, debido a la elegancia de realizar una aplicación web completamente en JavaScript. Ambas partes se entienden a las mil maravillas y podríamos decir que no sólo es por usar el mismo lenguaje, sino que de alguna manera ambos comparten el objetivo de construir servicios web sólidos y escalables.

Yendo un poco más allá, surge la idea de hacer una aplicación completa añadiendo al quit una base de datos NoSQL como MongoDB, que trabaja con JSON, una estructura de datos propia de JavaScript y una aproximación más moderna que la tradicional solución MySQL.

¿Es el futuro de los aplicaciones web y por ende de los servicios online una solución completa en javascript del estilo SproutCore + Node.js+ MongoDB? No lo sé, pero un servidor va intentar averiguarlo… y existe literatura interesante por donde empezar:

Proveedores de base de datos NoSQL:

[divider_padding]

¡No programeis mucho y Dios salve HTML5!


Gabriel Gómez Pérez
Gabriel Gómez Pérez
Responsable de los desarrollos informáticos y diseno de interacciones. Programador especializado en desarrollos front-end.