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

Question

OpenLaszlo es - por lo que yo sé - la única plataforma de aplicaciones ricas de Internet con las siguientes características:

• XML declarativa idioma de la interfaz de usuario basada en (similar a XUL de Mozilla) llama LZX.
• Compilación cruzada de LZX para JavaScript o ActionScript 3 (por lo tanto, es compatible con dos tiempos de ejecución).
• Posibilidad de desarrollar componentes utilizando 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 compatible con varios diseños predefinidos; los desarrolladores pueden implementar fácilmente diseños personalizados.
• Poderoso soporte para restricciones utilizando una sintaxis simple en atributos XML: $ once {JavaScript expression} o $ always {JavaScript expression}.
• Depurador incorporado (consola de desarrollador) que funciona en ambos tiempos de ejecución.

no he visto ningún marco más moderna JavaScript que hace que sea tan fácil como aplicaciones de OpenLaszlo para crear HTML5 - con el único inconveniente de que el actual conjunto de componentes entregado con OpenLaszlo parece un poco a Mac OS en 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 integra directamente en el servidor OpenLaszlo)? Escuché que Adobe intentó hacer algo similar con el prototipo del compilador FalconJS (consulte este Adobe video Open Discussion about Falcon and FalconJS para obtener más información), pero detuvo el esfuerzo. El código de la prueba de concepto FalconJS se contribuirá a la Apache Foundation 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 old Ajaxian article from 2007, leí que la versión final de Laszlo Webtop admitirá OpenLaszlo 4, lo que significará soporte para 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 this Stackoverflow discussion 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.

¿Existen 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.).

Answer 1

Empecé 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 de fuente abierta para mis necesidades.

Actualmente, mis aplicaciones aprovechan los tiempos de ejecución de SWF y JavaScript. Tan solo porque no están en el escaparate de Laszlo, ahora muerto, no significa que no haya aplicaciones grandes que aprovechen 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 de 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.

Answer 2

Expondré 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 Stackoverflow y me pareció que tenía todas las características de un proyecto moribundo (en revisión, evidencia here suministrada por Raju en los comentarios).

En relación con Gliffy, this article 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 HAXE/NME parece cubrir su requisito principal de poder compilar a tanto Flash como 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 elucubrar). 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.

Answer 3

Incluso en 2012 los desarrolladores web todavía se enfrentan a los problemas Laszlo intentaron 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 compatibilidad con 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 de revestimiento de consumo o de negocios siguen siendo diferentes: Muchas empresas

desarrollo de aplicaciones entre navegadores
Si conoce las API y las diferencias entre los navegadores, se puede lograr fácilmente 80-90% de lo que puede con Flash basado en 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 compatible).

El lenguaje LZX vs JavaScript puro
LZX sigue siendo un lenguaje fantástico para la construcción de grandes interfaces de usuario, utilizando un enfoque de desarrollo establecido. LZX ha evolucionado mucho: soporte de CSS, mixins, soporte para clases de codificación 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 a JavaScript como CoffeeScript.
Un gran número de desarrolladores que usaron el lenguaje LZX de OpenLaszlo y pasaron a usar marcos JavaScript como jQuery o Prototype se quejan de cuánto código 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 diseño Muchos de los desarrolladores de Flex que cambian al desarrollo de 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 la Adobe AIR SDK
Con el ActionScript 3 basada SWF10 11 de tiempo de ejecución /, cualquier aplicación OpenLaszlo se pueden compilar fácilmente en un archivo de Adobe AIR para Android o iOS aplicación. Mira este video que creé en 2010, mostrando un script Apache Ant compiling an OpenLaszlo app into an AIR for Android application 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 tal conjunto de componentes, 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.

de doble tiempo de ejecución y compilación cruzada para una mejor experiencia de usuario
Ha habido una serie de tecnologías en los últimos años permite a los desarrolladores de aplicaciones móviles para codificar una aplicación en un idioma, y ​​cross-compilar el código diferente 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.
Sistemas de Laszlo y David Temkin (ex CEO y CTO de Laszlo) estableció el término Cinematic User Experience:

experiencia del usuario cinemático transmite en primer lugar que usted no es sólo viendo que está interactuando - la “experiencia de usuario " Parte de ello. Nos pensamiento cinemático era un término intrigante, que tenía un giro no técnico a la misma. Era algo que cuando los no tecnológicos lo vieron, al instante entendieron que este es un tipo completamente diferente de categoría de producto y pero los conocedores de la industria lo mirarían y dirían que las cosas se mueven en la pantalla, quizás tengas una arquitectura técnica diferente ...

Uno de los objetivos de OpenLaszlo y LZX fue la de permitir la creación de tales experiencia del usuario cinematográfico, dando a los ingenieros de interfaz de usuario de las API y las herramientas en el lenguaje de programación (LZX) para reproducir exactamente la experiencia creada por UX diseñadores que usan herramientas como la herramienta de autoría Flash.

Aquí es una cita de a book on iOS app development, mostrando que otros ven el valor de este enfoque:

Uno de los conceptos que los ingenieros de Apple como de qué hablar cuando que están hablando de usuario beauti-ful interfaces es el concepto "experiencia de usuario cinemática". Una experiencia de usuario cinemática es esencialmente una interfaz de usuario que parece algo de una película de Hollywood. Es luce futurista-tic y suave, y usa animación para mejorar la sensación de 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 builduser interfaces que implican elementos que se deslizan desde fuera de la pantalla en lugar que apenas aparecen, y los elementos que se desplazan con una casi física peso a ellos

LZX y la cruz -compiler nos da 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, el LzPix demo: Created in 2006, sigue siendo una interfaz de usuario sorprendente, y no he visto nada parecido construido con marcos JavaScript.

doble de tiempo de ejecución sigue siendo válida
Sí, el enfoque de doble tiempo de ejecución sigue siendo válida. Debería haber más aplicaciones en el escaparate usando 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.

Answer 4

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 hacían que el código funcionara de manera diferente en diferentes navegadores impidió la finalización exitosa de ese intento.

El segundo intento fue utilizar 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 tomar fácilmente para construir 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 personal, los recursos para construir y mantener múltiples versiones no existía la aplicación para diferentes navegadores y sistemas operativos, OpenLaszlo resolvió ese problema en ese momento.

Estuvimos contentos cuando OpenLaszlo agregó el tiempo de ejecución de 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 sola vez 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/

Así que, creo, el doble de tiempo de ejecución de OpenLazlo sigue siendo válida, pero tal vez la pregunta es si OpenLazlo 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 de hacerlo.