¿El enfoque de doble tiempo de ejecución de OpenLaszlo(HTML5 y Flash/SWF) sigue siendo válido?

runtime lzx (4)

OpenLaszlo es, hasta donde sé, la única plataforma de aplicaciones de Internet con las siguientes características:

Lenguaje declarativo de interfaz de usuario basado en XML (similar al XUL de Mozilla) llamado LZX.
Compilación cruzada de LZX para JavaScript o ActionScript 3 (por lo tanto, es compatible con dos tiempos de ejecución).
Capacidad de desarrollar componentes usando solo XML y JavaScript o JavaScript; todos los componentes son renderizados por OpenLaszlo, por lo tanto se verán idénticos en todos los navegadores y dispositivos.
Ver la administración del sistema, el teclado y el mouse trabajando en tiempo de ejecución.
El componente se puede escribir en LZX (XML + JavaScript), o solo en JavaScript
Conjuntos de datos XML compatibles con la asignación basada en XPath de los componentes a los elementos del conjunto de datos.
Motor de diseño que admite varios diseños predefinidos; los desarrolladores pueden implementar fácilmente diseños personalizados.
Potente soporte para restricciones usando una sintaxis simple en atributos XML: $ once {JavaScript expression} o $ always {JavaScript expression}.
Depurador integrado (consola de desarrollador) que funciona en ambos tiempos de ejecución.

No he visto ningún framework de JavaScript más moderno que haga que sea tan fácil como OpenLaszlo crear aplicaciones HTML5, con el único inconveniente de que el conjunto de componentes actual entregado con OpenLaszlo se parece un poco al Mac OS de los años 90.

¿Pero qué tan válido es el enfoque de implementar una aplicación como aplicación HTML5 / JavaScript y como una aplicación Adobe Flash (con la opción de crear una aplicación móvil basada en Adobe AIR, aunque esa funcionalidad no se incorpore directamente al servidor OpenLaszlo)? Escuché que Adobe intentó hacer algo similar con el prototipo del compilador FalconJS (vea este video de Adobe, Discusión Abierta sobre Falcon y FalconJS para más información), pero ellos detuvieron el esfuerzo. El código de la prueba de concepto de FalconJS se contribuirá a la Fundación Apache como parte del proyecto Apache Flex, pero

Es sorprendente ver que no hay una sola aplicación que utilice ambos tiempos de ejecución en la sección de presentación de OpenLaszlo: http://www.openlaszlo.org/showcase

En un viejo artículo de Ajaxian de 2007 , leí que el "lanzamiento final de Laszlo Webtop apoyará OpenLaszlo 4, lo que significará compatibilidad con aplicaciones Ajax y Flash". Pero el sitio de demostración de Laszlo Webtop http://gowebtop.com/webtop/ solo tiene una versión basada en Flash de Webtop. He leído en esta discusión de Stackoverflow que Gliffy , una de las aplicaciones de OpenLaszlo más impresionantes que conozco, ha sido reconstruida usando JavaScript, sin utilizar la capacidad de doble tiempo de ejecución de OpenLaszlo.

¿Hay otras aplicaciones grandes de OpenLaszlo implementadas como HTML5 / DHTML y Flash, que tal vez no están incluidas en el sitio web de OpenLaszlo.org? Incluso si Flash ya no es tan popular, sigue siendo una tecnología relevante para una serie de casos de uso (conferencias de audio, 3d en el navegador, reproducción de video acelerado por GPU, etc.).

Comencé a usar OpenLaszlo en el año 2004 después de que concluí que en ese momento no había una mejor herramienta de RIA gratuita y de código abierto para mis necesidades.

Mis aplicaciones actualmente aprovechan los tiempos de ejecución de SWF y JavaScript. Así que el hecho de que no estén en el escaparate Laszlo ahora muerto no significa que no haya aplicaciones grandes aprovechando ambos tiempos de ejecución. He estado trabajando en mis aplicaciones durante 7 años. Gliffy es un juego de juguete en comparación en mi humilde opinión ... Todavía no he encontrado ninguna aplicación OL más compleja que la mía. No quiere decir que no estén ahí afuera, pero si lo son, no los he visto.

Mis aplicaciones no serían factibles con solo uno u otro tiempo de ejecución. Entonces para mí, tener ambos tiempos de ejecución es esencial. HTML5 es demasiado lento para ciertas cosas, mientras que SWF10 ofrece la experiencia más consistente entre navegadores.

HAXE no es un reemplazo OL, eso es seguro. El valor de OL para mí ha sido el aumento de productividad obtenido de las restricciones, la programación basada en instancias y la facilidad para vincular datos a las vistas. No podría haber construido mis productos por mi cuenta con ninguna otra herramienta. Miré por todas partes. Con OL en declive y ahora casi muerto, sigo buscando, también. El tiempo de ejecución HTML5 de OL no funciona en las últimas versiones de IE, lo que apesta ... pero se puede ejecutar a través del modo de emulación IE7 o el complemento de cuadro de Chrome (que es realmente esencial debido al motor JavaScript de IE).

Si necesita ambos tiempos de ejecución depende de su proyecto. Aunque probablemente no tenga sentido que los compiladores piensen que es posible emitir tanto tiempos de ejecución de SWF como HTML5, dado que OL ha podido hacerlo durante años, ahora hay algunos sistemas como el mío que se aprovechan de eso. capacidad.

Como ejemplo, mi sistema se está utilizando en redes militares clasificadas que no permiten el complemento de Flash ... por lo que para esas instalaciones debo confiar en HTML5. Cuando no se ejecuta en redes clasificadas, mi sistema aprovecha el rendimiento del tiempo de ejecución y otras capacidades del tiempo de ejecución de SWF cuando es ventajoso. El enfoque híbrido es esencial para mí. Si tuviera una aplicación SWF-only no estaría permitida en redes clasificadas, pero si fuera solo HTML5, la porción de la aplicación sería menos que estelar debido a las limitaciones del navegador.

Incluso en 2012, los desarrolladores web todavía enfrentan los problemas que Laszlo intentó resolver cuando la compañía creó inicialmente OpenLaszlo . Hace 10 años, Flash era la única tecnología de navegadores cruzados que ofrecía un renderizado perfecto para el 97% de los navegadores de escritorio, donde se instaló el complemento.
Los motores de JavaScript, HTML y CSS tienen mucho más que ofrecer ahora: reproducción de audio y video, incrustación de fuentes, animación basada en CSS, procesamiento de contenido acelerado por hardware, API de dibujo, últimamente soporte de videoconferencia en algunos navegadores (Chrome, Firefox y Opera basado en WebRTC). Los navegadores modernos ofrecen casi las mismas características que Flash, pero todavía hay cierto porcentaje de usuarios navegando por la web con una versión anterior de Internet Explorer que IE9.
Los requisitos para las aplicaciones comerciales o de cara al consumidor siguen siendo diferentes: muchas empresas

Desarrollo de aplicaciones entre navegadores
Si conoces las API y las diferencias entre los navegadores, puedes lograr fácilmente el 80-90% de lo que puedes con Flash en base a estándares abiertos. Pero aún depende de la experiencia de sus desarrolladores, con Flash tiene una API de ActionScript, que usa en todos los navegadores (al menos para Windows y OS X, Linux tiene algunas limitaciones y no es bien compatible).

El lenguaje LZX vs JavaScript puro
LZX sigue siendo un lenguaje fantástico para construir grandes IU, utilizando un enfoque de desarrollo establecido. LZX ha evolucionado mucho: soporte de CSS, mixins, soporte para codificar clases en JavaScript en lugar de XML, la capacidad de incrustar código de ActionScript 3 en el lenguaje son algunas de las nuevas características.
Hace 6 años, mucho después de la creación de LZX, muchos desarrolladores no sabían cómo escribir un buen código JavaScript. El modelo de desarrollo basado en prototipos no estaba bien documentado, y los desarrolladores tendían a usar JavaScript como Java / OOP, lo que daba como resultado un código horrible. E incluso en 2012, con muchos buenos libros sobre JavaScript en el mercado y millones de emocionados desarrolladores de JavaScript, crear interfaces complejas usando JavaScript puro no es una tarea fácil. Hay una razón para la popularidad de los lenguajes de compilación cruzada de JavaScript como CoffeeScript .
Un gran número de desarrolladores que usaron el lenguaje LZX de OpenLaszlo y pasaron a utilizar marcos JavaScript como jQuery o Prototype se quejan de la cantidad de código que se necesita para lograr lo que se puede hacer con unas pocas líneas de código LZX usando datasets, databinding, replication y el sistema de disposición. Muchos de los desarrolladores de Flex que cambian al desarrollo HTML5 / JavaScript se quejan de las mismas cosas. Tener el poder de LZX y poder compilar de forma cruzada tanto SWF como JavaScript es, por lo tanto, algo extremadamente valioso.

OpenLaszlo y Adobe AIR SDK
Con el tiempo de ejecución de SWF10 / 11 basado en ActionScript 3, cualquier aplicación de OpenLaszlo se puede compilar fácilmente en una aplicación de Adobe AIR para Android o iOS. Mira este video que creé en 2010, que muestra un script de Apache Ant compilando una aplicación OpenLaszlo en una aplicación AIR para Android y desplegando la aplicación en el teléfono. Ese flujo de trabajo funciona con la última versión (no publicada) de OpenLaszlo 5.0. Lo que falta es que no hay un conjunto de componentes optimizados para dispositivos móviles y táctiles para OpenLaszlo en este momento. Pero no sería demasiado trabajo crear un conjunto de componentes tal, si los miembros activos de la comunidad estarían dispuestos a contribuir a dicho proyecto. Esto significa que puede usar LZX para desarrollar aplicaciones móviles con buen rendimiento en teléfonos inteligentes y tabletas modernos, sin la necesidad de aprender Objective C o Java para el desarrollo de Android. Haxe es otro proyecto de código abierto que usa mucho la compilación cruzada para apuntar aún más tiempos de ejecución: JavaScript, Flash, NekoVM, PHP, C ++, C # y Java.

Dual-runtime y compilación cruzada para una mejor experiencia de usuario
Ha habido una serie de tecnologías en los últimos años que permiten a los desarrolladores de aplicaciones móviles codificar una aplicación en un idioma y compilar de forma cruzada el código de otras plataformas móviles. Puede hacer lo mismo con OpenLaszlo, y podría agregar otros tiempos de ejecución fácilmente debido a la arquitectura modular (componentes escritos en LZX, LFC escritos en LaszloScript / JavaScript, kernel escrito en lenguaje específico de tiempo de ejecución, por ejemplo, ActionScript3). Pero a mis ojos hay una razón aún más importante para usar un lenguaje como LZX y compilación cruzada para JavaScript, ActionScript 3 u otros lenguajes o máquinas virtuales. Tiene que ver con la capacidad de crear impresionantes efectos visuales y una experiencia de usuario única, que es habilitada por LZX y difícil de lograr con el desarrollo de JavaScript puro.
Laszlo Systems y David Temkin (el ex CEO y CTO de Laszlo) establecieron el término Experiencia de usuario cinemática :

La experiencia cinemática del usuario transmite, en primer lugar, que no solo está observando que está interactuando, sino también la parte de "experiencia del usuario". Pensamos que el cinematógrafo era un término intrigante, que tenía un giro no técnico. Fue algo que cuando los no tecnológicos lo vieron, inmediatamente entendieron que este es un tipo de producto completamente diferente y, sin embargo, los conocedores de la industria lo mirarían y dirían que las cosas se mueven en la pantalla, tal vez tengas una arquitectura técnica diferente ...

Uno de los objetivos de OpenLaszlo y LZX era permitir la creación de dicha experiencia cinemática de usuario, proporcionando a los ingenieros de UI las API y las herramientas del lenguaje de programación (LZX) para reproducir exactamente la experiencia creada por los diseñadores de UX utilizando herramientas como la creación de Flash. herramienta.

Aquí hay una cita de un libro sobre el desarrollo de aplicaciones de iOS , que muestra que otras compañías ven el valor de ese enfoque:

Uno de los conceptos que les gusta hablar a los ingenieros de Apple cuando hablan de interfaces de usuario bellas es el concepto de "experiencia de usuario cinemática". Una experiencia de usuario cinemática es esencialmente una interfaz de usuario que se parece a una película de Hollywood. Se ve futurista-tic y suave, y utiliza animación para mejorar la sensación de trabajar con objetos físicos.
Los diseñadores de la interfaz de usuario de Apple le han proporcionado específicamente un conjunto de herramientas que le permiten construir estos tipos de interfaces de usuario cinemáticas. Herramientas como Core Animation le dan el poder de construir interfaces de usuario que involucran elementos que se deslizan desde fuera de la pantalla en lugar de simplemente aparecer, y elementos que se desplazan con un peso casi físico para ellos

LZX y el compilador cruzado nos dan las herramientas para crear esta experiencia de usuario especial. Podría hacer lo mismo con JavaScript, pero sería más código, y probablemente mucho más difícil. Un buen ejemplo es la primera aplicación OpenLaszlo que se ejecuta en DHTML, la demo de LzPix : Creada en 2006 , sigue siendo una interfaz de usuario increíble, y no he visto nada parecido construido con marcos de JavaScript.

Dual-runtime sigue siendo válido
Sí, el enfoque de doble tiempo de ejecución sigue siendo válido. Debería haber más aplicaciones en el escaparate utilizando el tiempo de ejecución DHTML, y no sé por qué no es así. El hecho de que OpenLaszlo no haya sido optimizado para el iPad o las tabletas definitivamente es una desventaja, pero el tiempo de ejecución DHTML podría optimizarse para iOS y Android. Si se eliminan las peculiaridades del navegador de escritorio, se crearía un nuevo conjunto de componentes optimizado para navegadores móviles (utilizando canvas HTML y CSS2 / 3 para representar los componentes), tendría un tiempo de ejecución móvil sólido para OpenLaszlo.

Voy a advertir esto primero diciendo que no va a ser una respuesta completa; sin embargo, es de esperar que parte de la información te sea útil.

Miré a OpenLaszlo recientemente en relación con otra pregunta sobre y me pareció que tenía todas las características de un proyecto moribundo (en la revisión, la evidencia aquí proporcionada por Raju en los comentarios).

En relación con Gliffy, este artículo proporciona una idea de su lógica para abandonar OpenLaszlo. En particular, mencionan el problema de los tiempos de compilación y el efecto que esto estaba teniendo en su tiempo de desarrollo.

Definitivamente no marca todas sus casillas (específicamente, no creo que haya soporte para un lenguaje de UI declarativo basado en XML), pero parece que HAXE / NME cubre su requisito básico de ser capaz de compilar tanto en Flash como en HTML5 .

Divulgación justa, en realidad no lo he usado, pero sigo oyendo cosas buenas sobre él (acabo de asistir a una conferencia de desarrollo creativo en la que escuché al menos a 2 oradores elogiarlo). Básicamente es ActionScript 3.0, menos las principales molestias y además las principales omisiones (clases abstractas, por ejemplo). Por lo tanto, debería ser fácil de aprender, si ya conoce ActionScript 3.0, y una experiencia agradable para trabajar de cualquier manera.

Elegimos OpenLaszlo en 2006 para implementar nuestra aplicación de edición de video en línea (http://www.sarolta.tv/web/sarolta-tools/template-editor.html) después de dos intentos para crearlo usando diferentes plataformas.

El primer intento fallido fue el uso de DHTML, pero la complejidad de hacerlo en JavaScript + HTML puro y las peculiaridades del navegador que hacen que el código funcione de manera diferente en diferentes navegadores impidió la finalización exitosa de ese intento.

El segundo intento fue usar Adobe Flash puro, pero la naturaleza orientada a la línea de tiempo de Flash era un concepto extraño para los desarrolladores que les dificultaba crear lo que se quería.

Finalmente, se eligió OpenLaszlo, que era una combinación intuitiva de XML más JavaScript que cualquier persona con un poco de experiencia con programación OO y diseño web podría elegir fácilmente para crear aplicaciones complejas en Flash. En ese momento, OpenLaszlo solo admitía Flash, pero todos los navegadores de todos los sistemas operativos admitían Flash. Nos gustó que Flash fuera multiplataforma porque el código funcionaría de la misma manera en todos los navegadores, lo que no era el caso con las aplicaciones DHTML basadas en JavaScript. En ese momento, el 97% de los sistemas admitía Flash, por lo que tampoco era necesario que el usuario instalara ningún software para que nuestra aplicación funcione en su sistema.

Como una empresa de nueva creación con un número limitado de empleados, los recursos para construir y mantener múltiples versiones, la aplicación para diferentes navegadores y sistemas operativos no existía, OpenLaszlo resolvió ese problema en ese momento.

Estuvimos contentos cuando OpenLaszlo agregó el tiempo de ejecución DHTML y cuando nos enteramos de que IBM estaba trabajando en un Java (ahora abandonado) tiempo de ejecución de OpenLaszlo, ya que esto significaría que nuestro código sería compatible con el mercado móvil emergente y otros dispositivos. Desafortunadamente, ningún desarrollador oficial de OpenLaszlo que trabaja en sistemas Laszlo ha realizado mucho trabajo desde octubre de 2010, por lo que el tiempo de ejecución DHTML / HTML5 no ha mejorado desde entonces.

Creo que el enfoque de escribir una vez en cualquier lugar es algo que todavía es muy deseable, incluso hoy en día. Ser obligado a lidiar con las peculiaridades del navegador y del sistema operativo que hacen que su aplicación funcione de manera diferente en diferentes sistemas es una molestia y requiere mucho tiempo de mantenimiento. Creo que la razón por la que JQuery y especialmente JQuery Mobile es tan popular hoy en día es porque está diseñada para ser multiplataforma e invisiblemente trata con las peculiaridades del navegador / sistema operativo para que usted no tenga que preocuparse por eso. JQuery Mobile es compatible con casi todas las plataformas:

http://jquerymobile.com/gbs/

Entonces, creo, el doble tiempo de ejecución de OpenLaszlo sigue siendo válido, pero tal vez la pregunta es si OpenLaszlo sigue siendo válido después de casi dos años sin ningún lanzamiento oficial, mientras que otros frameworks de JavaScript mejoran y evolucionan constantemente para reemplazar la necesidad.