La alegría de Haxe. Una novela con un lenguaje de programación descuidado

Hola Habr! Te presento la traducción de La alegría de Haxe. La historia de amor de FontStruct con un lenguaje de programación descuidado .


Un intento bastante crudo de reproducir el logotipo de Haxe en el editor de fuentes FontStruct

Recientemente abrimos el código fuente para la parte más importante de nuestro módulo de creación de fuentes. Esta es la biblioteca fonthx para crear fuentes TrueType, y está escrita en Haxe .
Prácticamente no hay código en este artículo. Si solo está interesado en el código, puede familiarizarse con él en github , y su trabajo se muestra en el ejemplo del editor de fuentes de píxeles más simple creado con la biblioteca fonthx.

Independientemente de si está familiarizado con Haxe o no, el proyecto fonthx puede ser de su interés, ya que demuestra algunas características sorprendentes del lenguaje que son poco conocidas fuera de la comunidad Haxe, en particular, la capacidad de escribir código en un idioma agradable con una mayor compilación / traducción no solo es en Javascript, pero también en muchas otras plataformas, en el caso de fonthx, tales plataformas son JVM (el código del proyecto se traduce en Java), código nativo (C ++ o C #), NodeJS o WASM.

Me pueden llamar un políglota convencido. Al igual que muchos otros desarrolladores, escribo código en diferentes idiomas y, respetando las serias intenciones de aquellos que prefieren especializarse en un solo idioma, también temo a todos aquellos fanáticos y estafadores evangélicos que hablan de un idioma verdaderamente verdadero. Pero, ¿qué me llevó a utilizar un lenguaje de nicho como Haxe para crear los componentes clave de FontStruct, así como para escribir este artículo? ¿Y qué es Haxe?

Haxe

Haxe es un lenguaje de programación moderno, fuertemente tipado con algunas características interesantes y una pequeña biblioteca estándar.

La característica más importante de un lenguaje es su capacidad para compilar el mismo código para diferentes plataformas de destino.

La mayoría de los desarrolladores están familiarizados con el concepto de desarrollo "isomorfo" cuando un programador escribe el código del servidor y del cliente en un idioma. Muy a menudo, Javascript o TypeScript se usa como tal lenguaje, pero también se puede usar cualquier otro lenguaje capaz de compilarse en Javascript. Haxe va mucho más allá en esta dirección, abriendo una serie de interesantes oportunidades adicionales. Es posible compilar un archivo ejecutable, una aplicación Java, un módulo WASM, una aplicación NodeJS, una aplicación basada en navegador, una aplicación móvil e incluso bibliotecas para lenguajes como PHP, Lua o Python desde una base de código en Haxe.

En FontStruct, aprovechamos esta oportunidad desarrollando componentes clave de nuestra aplicación Haxe. Los módulos del servidor se compilan como servlets de Java, y los módulos del cliente se compilan como aplicaciones JS. Aunque actualmente nos estamos centrando principalmente en estas dos plataformas de destino (así como en NodeJS para ejecutar pruebas de velocidad), también estamos considerando usar las herramientas proporcionadas por el ecosistema Haxe para crear aplicaciones móviles en C ++. Además, el uso de Haxe en el futuro puede permitir la creación de una aplicación de escritorio nativa (no basada en Electron).

Debido al hecho de que Haxe admite tantas plataformas de destino, es mejor que nadie (al menos para nuestras tareas) implementa la idea de "escribir código una vez, ejecutarlo en todas partes", mejor que cualquier herramienta con la que me haya encontrado en los últimos veinte años. Esto da la sensación de que se puede compilar el mismo código para cualquier plataforma o tiempo de ejecución.

Proceso de adopción de Haxe

FontStructor - Editor de fuentes gratuito en FontStruct.com

Hace más de 10 años, cuando se lanzó FontStruct, Adobe Flash se usó para el editor de fuentes FontStructor, así como widgets para ver fuentes. Y para crear fuentes TrueType en el servidor, se utilizó un código completamente independiente escrito en Java.


Antigua versión Flash del editor FontStructor. Todos los controles en él fueron dibujados en Flash. Observe las extrañas barras de desplazamiento en los paneles a la izquierda. Con el tiempo, el menú principal en la parte superior de la página se separó gradualmente visual y funcionalmente del menú html utilizado en el resto del sitio. No hay DOM o CSS aquí

Aunque FontStruct ha sido y sigue siendo un gran éxito, nuestras soluciones técnicas iniciales no han pasado la prueba del tiempo. El desarrollo de estándares web y la falta de soporte de complementos en plataformas móviles han hecho que Flash no sea apto para su uso en aplicaciones web. También tuvimos que lidiar con la duplicación de código entre un servidor Java y un cliente Flash, así como entre Flash y otras partes del cliente escritas en HTML / JS / CSS. Era necesario sincronizar constantemente entre sí las tres bases del código, tanto en términos de funcionalidad como de diseño.

En 2013, comenzamos a considerar la posibilidad de utilizar Haxe, en particular, como un medio para traducir el editor FontStructor de Flash a HTML5. En nuestra investigación inicial, descubrimos que ya hay herramientas disponibles para convertir automáticamente el código ActionScript a Haxe ( as3hx ) e incluso el puerto Haxe del marco MVC de Robotlegs que utilizamos en la versión Flash. Y así comenzamos el experimento de portar al cliente.

Comienzo lento y problemático

Nuestro primer año de relación con Haxe estuvo acompañado de indecisión y duda.

Por varias razones, y no solo por los recursos limitados que podríamos dedicarle, el proceso de transferencia resultó ser bastante lento. Como ya han señalado otros autores , la herramienta para convertir automáticamente el código ActionScript a Haxe (as3hx) resultó ser muy útil, pero no sin inconvenientes: el código obtenido con él tuvo que revisarse y editarse adicionalmente. Durante este proceso, quedó claro que nuestra base de código estaba hinchada y tenía un diseño erróneo, por lo que, en paralelo con la transferencia, decidimos hacer mejoras, lo que ralentizó aún más el progreso. Además, Haxe era un nuevo idioma para nosotros, por lo que inevitablemente cometimos errores al estudiar este idioma y sus herramientas.

Con mucho, nuestro mayor error fue la decisión de utilizar adicionalmente un marco de interfaz de usuario de terceros en Haxe.

Para Haxe, existen muchos marcos de este tipo (quizás incluso demasiados) que proporcionan una API unificada para representar gráficos en varias plataformas. OpenFL y NME son ejemplos de dichos marcos y proporcionan herramientas para crear aplicaciones Haxe para plataformas móviles e incluso consolas. Al hacerlo, proporcionan una implementación de API Flash para renderizar gráficos. Todo esto parecía muy tentador: ¡podíamos transferir nuestra aplicación a HTML5 usando la API familiar y, tal vez, incluso crear aplicaciones para Android e iOS al mismo tiempo!

Por lo tanto, decidimos usar OpenFL para portar nuestra aplicación a Haxe.

No quiero faltarle el respeto a OpenFL (incluso quiero decir que: "El problema no está en OpenFL, sino en nosotros"). OpenFL es un proyecto fantástico que se ha mostrado bien en muchos proyectos, y podemos volver a él en el futuro, pero después de transferir aproximadamente el 90% de nuestra aplicación a Haxe, decidimos abandonarlo.

OpenFL resultó ser una dependencia mucho más seria de lo que esperábamos. Originalmente se planeó que se usaría solo como una biblioteca externa para nuestra interfaz de usuario, pero al final resultó que OpenFL estaba arrastrando sus propias herramientas para construir proyectos, formatos de archivo especiales para describir proyectos, así como dependencias externas adicionales. Quizás esto se deba al hecho de que, como la mayoría del ecosistema Haxe, OpenFL intenta satisfacer las necesidades de los desarrolladores de juegos independientes, mientras se desarrolla con bastante rapidez y la atención principal en su desarrollo se presta para agregar nuevas funciones, no estabilidad.

Lo más importante para nosotros fue que el código HTML5 generado con OpenFL es ideal para juegos, pero no es adecuado para una aplicación como FontStruct. Todo lo que queríamos al final era mostrar en el navegador un árbol DOM normal que pudiéramos diseñar con CSS, y no un conjunto de elementos de lienzo o sprites creados por OpenFL.

Necesitábamos HTML5 regular, no un intento de replicar Flash en un navegador sin usar complementos adicionales.

Divertido

Tan pronto como abandonamos el uso de OpenFL y nos dimos cuenta de que podíamos hacer lo que quisiéramos usando solo Haxe, todo fue más rápido, más fácil y, en última instancia, mucho más divertido.

Y trabajar con Haxe es divertido. Se puede decir que fue creado por expertos divertidos, desarrolladores de juegos independientes. Los desarrolladores de juegos necesitan una compilación rápida, así como una base de código único para crear aplicaciones para computadoras de escritorio, navegadores, iOS, Android y consolas. Los desarrolladores de juegos necesitan un código productivo y estable. Y Haxe ofrece todas estas excelentes funciones, y no solo para los desarrolladores de juegos.

No tengo miedo de expresar la idea de que uno de los mayores problemas de Haxe, el tamaño relativamente pequeño de su comunidad y la escasez relacionada de su ecosistema, también es su ventaja en términos de experiencia para el desarrollador. Cuando trabaje con Haxe, es poco probable que pase horas buscando en Google y buscando información sobre el desbordamiento de pila, o analizando y comparando diferentes lecciones sobre un tema de interés, así como mientras estudia la API de algún nuevo marco o biblioteca: estas respuestas, lecciones y Es posible que las bibliotecas simplemente no existan. Y si es así, lo más probable es que sean los únicos materiales sobre estos temas. Con Haxe, resolverá los problemas de programación usted mismo (!), Escribirá bibliotecas usted mismo o, sin experimentar el más mínimo sentimiento de culpa, incluso reinventará o portará la rueda usted mismo. Esto es divertido y da libertad, y esto es por lo que muchos desarrolladores se esfuerzan por obtener marcos infinitos y un desarrollo moderno relacionado con la copia de código de diferentes fuentes. Utilizando el principio de "menos es mejor", Haxe no es único, pero es su ventaja definitiva.

Haxe le da al programador oportunidades únicas. Da una sensación especial de asombroso descubrimiento y alegría. Al usar Haxe, con su capacidad de compilar código para muchas plataformas de destino, existe la sensación de que el programador está libre de una de las dependencias más fundamentales de todas las existentes: el tiempo de ejecución.

Renderer FontStruct

El lanzamiento de nuestro primer componente Haxe para el sitio FontStruct en abril de 2015 fue un evento extraño e inesperado.

La galería es una parte central de FontStruct: listas buscables y ordenables de miles de fuentes creadas en nuestra plataforma. Desde el comienzo en 2008, tuvimos problemas constantes con la velocidad de descarga y con el rendimiento de las vistas previas de fuentes tanto en la galería como en otras páginas del sitio.


La parte de la página de la galería FontStruct donde se muestra la vista previa de las fuentes creadas en la plataforma. Inicialmente, cada elemento de vista previa individual se presentó con una película Flash de carga lenta.

Dado que las fuentes FontStruct ("FontStructions") se almacenan en un formato propietario y a menudo se editan, es imposible usarlas para renderizar como fuentes TrueType normales. Esto significó la imposibilidad de crear imágenes de mapa de bits en el servidor para obtener una vista previa de las fuentes (utilizando la biblioteca FreeType).

Para "resolver" este problema, en los primeros días de FontStruct, utilizamos películas Flash separadas para elementos de la galería. Cada película Flash descargó y analizó datos en nuestro formato propietario, y luego mostró la imagen en el cliente para la vista previa. Al mostrar en la página 20 o más de tales clips, cada uno de los cuales descargó datos e intentó dibujar una fuente, el tiempo de carga y el consumo de recursos de la máquina del usuario aumentaron significativamente, y la situación se agravó aún más con el tiempo, a medida que las fuentes desarrolladas en nuestro editor se volvieron más y más y más complejo

Al final, utilizamos una solución híbrida elegante: la primera vez que miramos la fuente, utilizamos una película Flash que generaba una imagen para la vista previa, luego esta imagen fue capturada y guardada en el servidor como archivos PNG. Y para la vista previa de los siguientes usuarios, los que se guardaron en el servidor PNG ya se usaron. - Este extraño truco mejoró enormemente el tiempo de carga de la página, pero estaba sucio y, en última instancia, estaba mal o algo así. La decisión correcta sería escribir un módulo de servidor completamente nuevo, por ejemplo, en Java o PHP, para cargar y analizar datos de fuentes, y luego crear un mapa de bits basado en él, pero simplemente no teníamos los recursos para hacerlo.

Mientras tanto, el proceso de transferencia de Fontstructor a Haxe estaba progresando muy lentamente, y estábamos lejos del lanzamiento. Pero hemos llegado lo suficientemente lejos como para comprender que el nuevo código Haxe puede resolver nuestros problemas con la vista previa de las fuentes en la galería.

Ya teníamos código Haxe para cargar y analizar nuestro formato de fuente. Teníamos código para representar glifos (en Canvas en HTML5 o en sprites en Flash). También teníamos todos los componentes necesarios para resolver el problema en el lado del cliente. ¿Podríamos adaptar este código para usarlo en el servidor?

Si! Después de darnos cuenta de esto, el proceso fue muy rápido. Al principio pensamos en usar C ++ y la biblioteca Cairo para renderizar fuentes (con la esperanza de poder escribir una extensión para PHP o algún módulo CGI), pero en su lugar decidimos usar Java. "¡Qué maravilloso es poder hacer una elección tan fundamental con solo unas pocas líneas de código y compilación condicional!" También podríamos usar NodeJS y node-canvas para esto, pero ya estábamos familiarizados con el proceso de creación y despliegue de servlets de Java, y Java tiene todas las funciones que necesitamos para dibujar y manipular mapas de bits. Probablemente no nos gustó escribir código en Java, pero con Haxe, esto ya no es necesario.


Dicho código de representación de alto nivel se puede compilar y ejecutar tanto en el cliente (JavaScript) como en el servidor (en la JVM)

Como resultado, nos tomó solo unos días realizar cambios en nuestra base de código, y se lanzó un nuevo procesador. Durante la noche, mejoramos significativamente el rendimiento de la galería FontStruct, eliminamos el uso de hacks sucios y, lo más importante, lanzamos nuestro primer componente en Haxe para la batalla. Nos dimos cuenta de que Haxe puede sorprender y tiene capacidades mucho mayores de lo que esperábamos de él.

Adiós a Flash (y c Vanilla Java)

En noviembre de 2015, es decir, después de 7 meses, lanzamos con éxito el primer módulo de cliente Haxe: la versión HTML5 del widget para obtener una vista previa de las fuentes. Creo que nuestros usuarios casi no notaron los cambios, lo que por un lado decepciona de alguna manera, pero, en última instancia, es un indicador del éxito de esta iniciativa.

Ahora solo teníamos un módulo Flash en el sitio: el editor FontStructor, y nos llevó un año más lanzar finalmente su versión HTML5 en noviembre de 2016. Así que ha llegado el momento de abandonar finalmente nuestro código AS3 y declarar FontStruct libre de Flash.


Nueva versión HTML5 de FontStructor lanzada en 2016

En agosto de 2018, trasladamos el módulo de generación de fuentes FontMortar a Haxe. Este último puerto nos permitió abandonar completamente el código escrito en Java.

No estoy listo para usar Haxe para todo. Sí, sé que hay proyectos en los que se utiliza como herramienta principal para todos los aspectos del desarrollo web, pero estoy muy contento con el excelente marco de Symfony como base de nuestra aplicación web. FontStruct continúa usando muchos lenguajes de programación diferentes, pero la introducción de Haxe nos ha permitido reducir el tamaño y la complejidad de las partes más importantes de nuestro código. Para nuestra pequeña organización, esta simplificación ha demostrado ser vital para mantener y desarrollar la plataforma.

Profundizando en Hux

Si esta es la primera vez que escuchaste sobre Haxe y mi historia te interesó, entonces solo tengo que enumerar algunos hechos más sobre él.

• El soporte de idiomas por parte del IDE es bastante decente y mejora constantemente, los módulos para IntelliJ Idea y Visual Studio Code se están desarrollando activamente.
• Haxe proporciona herramientas para trabajar con código nativo y bibliotecas , por lo que no limita sus capacidades, imponiendo solo un pequeño subconjunto de las funciones disponibles. Si está desarrollando para JavaScript, tiene la oportunidad de utilizar cualquier biblioteca de JavaScript, por ejemplo, hay varios aglutinantes disponibles para trabajar con React. Para FontStructor, utilizamos varios módulos npm, como interactive.js y opentip. Escribir carpetas para ellos tomó solo un par de minutos.
• Haxe tiene un sistema de tipos avanzado y robusto con características como la parametrización de tipos , clases y métodos genéricos , tipos abstractos e inferencia de tipos .
• Haxe tiene macros extremadamente potentes que proporcionan acceso al AST en tiempo de compilación, lo que permite a los desarrolladores agregar sus propias construcciones de lenguaje y generar código dinámicamente.
• A pesar del hecho de que no hay muchos recursos en Haxe en Internet, hay un repositorio de bibliotecas para cubrir las necesidades generales de los desarrolladores fuera de la biblioteca estándar (además, en Github puede encontrar aún más repositorios que no están representados en haxelib - aprox. Traductor) .
• Por último, pero no menos importante, Haxe tiene una comunidad muy talentosa y receptiva .

Conclusión

Los desarrolladores más experimentados están listos para el cambio, pero son cuidadosos al elegir las tecnologías utilizadas. Es probable que en algún momento la mayoría de ustedes también tengan ganas de cambiar el lenguaje de programación dentro del marco del proyecto, especialmente cuando aparecen lenguajes nuevos y modernos con muchas características interesantes. Tuvimos cuidado al elegir Haxe, pensando en cuánto duraría nuestra relación. Nuestros pensamientos sobre él eran algo como esto :

suena genial, pero tiene una comunidad tan pequeña. ¿Qué le pasará en 5 años? El sitio parece ser normal, pero por alguna razón no parece moderno. Y esto no inspira confianza.
No parece estar tan bien documentado.

¿No es eso para los desarrolladores de juegos independientes?

Después de cinco años de usar Haxe, estoy sinceramente sorprendido de no lamentar nuestra elección de esta tecnología. A pesar de todas las deficiencias y todas las dificultades causadas por ellas, a pesar de la comunidad relativamente pequeña y la ausencia de grandes patrocinadores corporativos, Haxe está enfrentando plenamente sus tareas. Con Haxe, siento libertad e independencia de cualquier plataforma. Ahora tenemos una única base de código para los componentes principales de FontStruct, mientras que antes había dos de ellos. En los últimos meses, las versiones más nuevas de los servlets responsables de generar fuentes e imágenes para la vista previa nunca han fallado. El nuevo editor HTML5 y el widget de vista previa ahora funcionan en todos los navegadores, incluido el móvil, mientras que antes teníamos que trabajar con tecnología obsoleta y obsoleta.

Y, aparte de los beneficios prácticos, trabajar con Haxe trae alegría y un sentido de magia, ¡la alegría de Haxe !