Creo que es porque es un problema difícil de resolver bien.
HTML5 tiene muchas de las capacidades necesarias para construir y distribuir aplicaciones fuera de línea completas como Outlook y Powerpoint. Sin embargo, todavía hay mucho trabajo en el lado de la infraestructura para hacerlo realidad, especialmente si está tratando de reempaquetar una aplicación en línea para que sea capaz sin conexión.
Estos son algunos de los “huesos grandes” que veo por mi experiencia:
- Si tuviera $ 200k para desarrollar su idea de inicio web / móvil, ¿cómo lo gastaría?
- ¿Cuál es el significado de Travel CRS en el software del sistema de reservas?
- ¿Cuál es su opinión sobre Flux (arquitectura de la aplicación)?
- ¿Cuáles son las mejores opciones para hacer una aplicación web a gran escala?
- ¿Qué opinas sobre mi plataforma de currículum en línea?
1) Estados de la aplicación : uno de los grandes desafíos para hacer que una aplicación web en línea sea capaz de desconectarse es asegurarse de que todos los artefactos de la interfaz de usuario y la administración del estado (p. Ej., Pantallas, comportamiento y modelo) puedan dividirse en el cliente sin la necesidad de un servidor. Si bien las aplicaciones de Google están utilizando marcos controlados por Javascript-MVC (por ejemplo, marcos similares a Closure / GWT), todavía no es trivial dividir todos los componentes en modo dual.
En un modo en línea, generalmente diseña su aplicación para cargar componentes a pedido, sin embargo, para fuera de línea, debe poder empaquetar todos los componentes a la vez. En consecuencia, puede ser bastante difícil adaptar una aplicación en línea a una fuera de línea, incluso para las que ya tienen una arquitectura MVC de Javascript.
2) Almacenamiento indexado : una de las cosas más importantes que falta actualmente en la especificación HTML5 para aplicaciones fuera de línea es una API de almacenamiento local indexada. SQLite incrustado de Google Gears que resolvió el problema en todos los navegadores, sin embargo, sin Gears, solo los navegadores basados en WebKit (y Opera) admiten SQLite de fábrica. Hay una nueva iniciativa llamada indexDB que suena prometedora, pero aún es demasiado pronto para saber si será ampliamente compatible. Entonces, supongo que Google no sintió que valiera la pena implementar un “motor de indexación” además de la API HTML de almacenamiento local de pares de nombre / valor de hoy, y podría haber decidido trabajar primero con los organismos estándar para resolver este problema en el nivel de especificación HTML (Solo estoy adivinando obviamente).
3) Formato de archivo de documentos: otro problema está en el lado de documentos es que los documentos sin conexión requieren un formato de archivo portátil y “actualizable”. Supongo que, a partir de hoy, el “formato de contenido” de Google Docs es muy personalizado y necesitaría una revisión considerable para ser portátil. Crear un formato de archivo portátil no es una tarea trivial (desde un punto de vista técnico y de ingeniería social).
4) Protocolo de correo : esto no es realmente un problema para Google, ya que ya utiliza su propio protocolo HTTP patentado para acceder a su backend GMAIL. Pero si alguien más quería crear una aplicación HTML5 fuera de línea para Gmail, se bloqueará ya que no hay una API HTTP pública para acceder a los servicios de fondo de GMail. El uso de HTML5 WebSocket para acceder a la API de Gmail iMap / SMTP podría ser una posibilidad, pero podría ser bastante trabajo.
Entonces, nuevamente, creo que Google eventualmente llegará allí, ya que poner fuera de línea a la Web es fundamental para su visión, sin embargo, llevará tiempo. Al final del día, gran parte del trabajo requerido para las aplicaciones de escritorio tradicionales será necesario para hacer que las aplicaciones web estén fuera de línea.
