¿Hay alguna limitación de una aplicación web HTML5 idealista?

11

Supongamos que los siguientes dos supuestos son ciertos.

  • Toda su base de usuarios tiene acceso a banda ancha en todas partes
  • Existe un navegador imaginario X que implementa todo el borrador de la especificación de los grupos HTML5 y WHATWG, de manera consistente y todos los usuarios usan el navegador X.

¿Cuáles son las limitaciones intrínsecas de una aplicación web pública pública HTML5 para la que necesitamos aplicaciones de escritorio públicas comerciales?

Estoy interesado en las limitaciones de las aplicaciones web sin complementos que no dependen de los puentes Flash / Java / SilverLight / etc. para funciones adicionales ni de los complementos del navegador para funciones adicionales.

Posibles limitaciones que no se aplican:

  • Bases de datos? Tenemos WebSQL e indexedDB.
  • Archivo IO? Tenemos la API de archivos HTML5 que hace tanto lectura como escritura.
  • ¿Velocidad? Con la reciente carrera del motor de JavaScript, el navegador ya no es lento. Native C ++ es solo 3 veces más rápido que el motor V8 de Chrome.
  • ¿Herramientas de desarrollo? La web ha madurado y hay una gran variedad de herramientas disponibles que son demasiado numerosas para enumerarlas.
  • Fuente cerrada? Sí, todo el código es de código abierto. Esta es una espada de doble filo y hay numerosas opiniones sobre el uso de código cerrado o código fuente abierto. Personalmente, creo que las ventajas del código fuente abierto son mayores que las desventajas.
  • JavaScript / HTML5? Los argumentos en torno a "Personalmente creo que HTML5 y EcmaScript son plataformas de desarrollo horribles" no cuentan.

Limitaciones conocidas:

  • El código crítico en tiempo real / seguridad (alto secreto) no pertenece a la web ni puede. Debe escribirse en un lenguaje de bajo nivel y altamente controlable como C o C ++.
  • Cualquier herramienta que necesite interactuar con un hardware externo de terceros conectado a su computadora tendrá dificultades para hablar con su aplicación web.

También hay un conjunto completo de programas que no pertenecen a la web. Sistemas operativos, controladores, software de servidor, API de bajo nivel. Soy consciente de eso, pero no los clasifico como aplicaciones "públicas comerciales", estos son el tipo de software que se puede preinstalar en las computadoras.

Por otro lado, sé que las dos suposiciones son terriblemente poco realistas, pero podríamos lograrlas en 5/10/20/30 años. Estoy interesado en el tipo de aplicaciones y las características de las aplicaciones que las hacen completamente incompatibles con la web.

Motivación:

El punto:

Dado el conjunto de problemas donde una aplicación de escritorio es una solución válida.

  • ¿Por qué una aplicación web no es una solución válida?
  • ¿Cómo identifico si puedo usar una aplicación web como solución?

He tratado de eliminar las principales dificultades con las aplicaciones web (conexión a Internet y soporte de navegador) afirmando que no existen.

Además, las aplicaciones HTML5 fuera de línea y Modernizr están en camino de resolver ambos problemas.

¿Cuáles son las otras dificultades con el desarrollo de aplicaciones web?

Raynos
fuente
2
Limitación principal: una buena idea para la aplicación web que muchas personas querrán usar, conectada con un modelo de negocio que al menos devolverá los costos. El resto es lejos segundo.
SF.
"¿Cuáles son las limitaciones intrínsecas"? ¿Qué quiere decir con "limitación intrínseca"? ¿Qué significan estas palabras? ¿Qué información quieres? ¿Qué problema tienes? ¿Cuál es la pregunta?
S.Lott
@SF elimina la palabra "web". Necesitas un problema y una solución. Si esa solución es una aplicación, entonces necesita resolver el problema, tener una base de usuarios y tener un modelo de negocio que funcione. Solo estoy comparando el conjunto de problemas que tienen una aplicación de escritorio como solución y cuestionando por qué una aplicación web no funcionará.
Raynos
@ S.Lott su correcto, la pregunta era demasiado vaga, espero haber aclarado cuál es la pregunta real.
Raynos
¿Qué? "¿Cuáles son las limitaciones intrínsecas de una aplicación web pública comercial para la que necesitamos aplicaciones comerciales de escritorio público?" ¿Esto significa "cuándo necesitamos el escritorio porque la web no funcionará?" Si es así, todos estos son duplicados: programmers.stackexchange.com/search?q=desktop+web
S.Lott

Respuestas:

11

Fuera de mi cabeza ...

  • acceder a hardware propietario que exporta su E / S por otros medios que no sean un archivo. Ya sea un equipo científico, maquinaria industrial o una grabadora de CD simple y una tableta digitalizadora con soporte de inclinación.
  • solo HTTP y una pequeña familia de otros protocolos. No puede crear sockets como desee, transfiriendo los datos binarios que desee. Eso limita enormemente la conectividad con otros sistemas y servicios.
  • Ningún desarrollador sensato creará un juego de gráficos intensivos en Javascript. La banda ancha no es casi comparable a los rendimientos de DVD / HDD que a menudo se necesitan. La compatibilidad con 3D en Canvas es muy inferior a la que obtienes con los motores de juego. No hay forma de soportar el joystick, múltiples pulsaciones simultáneas de teclas, la naturaleza abierta facilita las trampas. Pero principalmente, la caída del rendimiento no es aceptable.
  • Sandboxing pesado. No obtendrá cosas que se integren profundamente en el sistema operativo. Capturas de pantalla, antivirus, unidades virtuales, tareas en segundo plano como la bandeja del sistema, tareas administrativas, etc.
  • No puede ser de misión crítica. Dependiendo de la banda ancha en todo momento, ejecutar su software básico no es la forma preferida de la mayoría de las empresas.
SF.
fuente
1
2. WebSockets expone un socket TCP. No tiene acceso a UDP en un navegador, pero TCP le ofrece muchas más opciones.
Raynos
2
3. WebGL está haciendo algunos progresos interesantes. El soporte de OpenCL ha comenzado recientemente. Claro que todavía faltan 5 años para el desarrollo de juegos de escritorio, pero está empezando a ser posible.
Raynos
2
@Raynos: WebSockets proporcionaría una funcionalidad similar a los sockets, pero requiere un protocolo de enlace específico, no puede adaptarlo fácilmente a los sistemas existentes, necesita modificaciones del lado del servidor. Lo que significa que no hay una aplicación web genérica de cliente ssh. WebGL podría resolver algunos de los problemas de gfx, aún no hay solución para los requisitos de datos masivos (gigabytes de texturas y mallas), E / S del controlador, y el soporte de audio es patéticamente pobre.
SF.
1
4. La API del dispositivo W3C (que no conocía) en realidad está sólidamente en camino de resolver los problemas de sandboxing.
Raynos
1
Muchas cosas han cambiado desde que escribiste esta respuesta. El navegador se ha convertido en una plataforma de software legítima por derecho propio; Gran parte de lo que describe en su respuesta ahora es posible. Sí, puedo imaginar casi cualquier juego o aplicación que se ejecute en el navegador, dado el esfuerzo suficiente.
Robert Harvey
3

Esencialmente, cualquier cosa que pueda encajar en el modelo de servidor / cliente puede ser una buena aplicación web e ispo facto lo contrario puede decirse que también es cierto. La tendencia a trasladarse a la web se ha ido muy rápidamente porque, al ver cómo la mayoría de los programas se pueden modelar en Modelo / Controlador / Vista, los programas pueden dividir el modelo y el controlador desde su vista.

Por supuesto, por razones de eficiencia, algunos controladores se colocan también en el lado del cliente para evitar sobrecargar el servidor con solicitudes y datos erróneos.

Aunque mi punto es: qué programas no se ajustan a la arquitectura del software modelo / controlador / vista, ya que probablemente sean los mismos programas que nunca se convirtieron en aplicaciones web. Buenos ejemplos que vienen a la mente son sistemas operativos, programadores de tareas, símbolo del sistema, protección contra virus, protección contra spyware. Es probable que no todos estén implementados en un sitio web porque no se ajusta al modelo. Y no es casualidad que cada uno de estos programas dependa en gran medida de su sistema. La mayoría requiere acceso directo al hardware, mientras que otros simplemente requieren una mayor seguridad para poder ejecutarse y no se puede confiar en los sitios web de Internet.

Por supuesto, Google está readaptando completamente este concepto con su nuevo sistema operativo. Supuestamente, a diferencia de Windows, no se trata simplemente de un sistema que creció para usar Internet, sino más bien un sistema que depende en gran medida de él. Pronto es posible que vea que todos estos programas están disponibles en línea, lo que permite el acceso a su hardware y software, dado un estricto certificado de autenticación para evitar que cualquier sitio pueda hacerlo, pero más bien sitios de confianza. Estoy ansioso por ver qué se les ocurre, ya que estoy pensando en 20 años, las computadoras ya no estarán hechas con software instalable. Más bien, todos los servicios estarán disponibles en línea.

Neil
fuente
0

• Cualquier herramienta que necesite interactuar con un hardware externo de terceros conectado a su computadora tendrá dificultades para hablar con su aplicación web.

El software en el que estoy trabajando ahora tiene un aspecto de escritorio y un aspecto basado en la web precisamente porque necesita recopilar datos de periféricos de terceros. La necesidad de desarrollo de controladores y un programa de escritorio del cliente para cerrar la brecha entre el dispositivo y la web.

Sin embargo, esto no excluye las aplicaciones web, ya que este tipo de aplicaciones de escritorio pueden ser delgadas y la lógica reside principalmente en el servidor.

Por otro lado, se puede decir con el aspecto de la computación en la nube y la virtualización masiva que ninguna aplicación necesita estar necesariamente limitada por las limitaciones y agujeros de seguridad de la tecnología web. Ejecutar aplicaciones de escritorio desde un entorno virtualizado en una terminal tonta (al igual que Citrix) se ha vuelto mucho más fácil de lograr y puede ser la próxima "moda" del desarrollo.

La conclusión es que ahora hay más opciones que nunca y muchas más personas que hablan de la tecnología del mañana como la "Mejor" forma.

árbol de arce
fuente
1
Curiosamente, puede ejecutar aplicaciones de escritorio desde un entorno virtualizado en un navegador web. La característica antigua de la mayoría de los servidores VNC es un applet Java de visor VNC, disponible de forma predeterminada en http: // [máquina remota]: 5800 / So - desktop-app-as-web-app?
SF.
0

Supongamos que los siguientes dos supuestos son ciertos.

  • Toda su base de usuarios tiene acceso a banda ancha en todas partes
  • Existe un navegador imaginario X que implementa todo el borrador de la especificación de los grupos HTML5 y WHATWG, de manera consistente y todos los usuarios usan el navegador X.

¿Cuáles son las limitaciones intrínsecas de una aplicación web pública pública HTML5 para la que necesitamos aplicaciones de escritorio públicas comerciales?

Estoy interesado en las limitaciones de las aplicaciones web sin complementos que no dependen de los puentes Flash / Java / SilverLight / etc. para funciones adicionales ni de los complementos del navegador para funciones adicionales.

Ok, entonces aquí está el problema: ese navegador, por su propia naturaleza, será inseguro. Entonces nos está pidiendo que hagamos un intercambio entre los dos. Sin embargo, superando eso, y suponiendo que tenemos javascript (al que mencionó en su publicación), la respuesta es que no hay una aplicación que no se pueda escribir usando solo HTML5 / Javascript. Sin embargo, asumimos un navegador que no se interpone en el camino.

La cosa tiene una tienda de base de datos local, puede hacer llamadas a cualquier otra plataforma utilizando solicitudes HTTP (que RESTafarian le dirá que es suficiente) y puede dibujar (a través de Canvas) casi cualquier cosa que desee. Ya hay juegos en 3D escritos con estándares abiertos (OpenGL ish) y hay API para hacer lo que quieras.

El único inconveniente real es la velocidad. Tomará tiempo hacer esas llamadas HTTP API a otros sistemas (bases de datos). Tomará tiempo procesar las solicitudes de ARCHIVO (COM1 :) (para leer en un dispositivo serie en Windows, por ejemplo), por lo que esas son las áreas problemáticas que esperaría. Por supuesto, también supongo que los controladores están escritos para acceder a ellos como archivos, lo que estoy bastante seguro de que ya no es cierto. Pero podrían exponer tal mecanismo;)

Para el usuario, no mucho será diferente en absoluto.

jcolebrand
fuente