Solo estoy desahogándome aquí, pero después de haber usado más lenguajes de plantillas de las que me gustaría recordar (Jinja2, ERB, FTL, XSLT, JSX, Handlebars, etc.), encuentro que Hyperscript es absolutamente horrible de trabajar.
Sin un orden particular, los problemas que presenta incluyen:
Portabilidad del código (no se pueden copiar/pegar fragmentos de HTML sin pasarlos por un conversor)
Resaltado de sintaxis (lo convierte todo en un gran bloque) por ejemplo
Sí, estoy de acuerdo en que no es lo mejor para trabajar, especialmente en comparación con Handlebars (que también usamos), donde puedes escribir HTML tal como esperas.
Comenzamos a usar virtual-dom/virtual-hyperscript en lugares donde necesitábamos mejorar el rendimiento. El tema de nuestros múltiples sistemas de plantillas es algo de lo que hemos empezado a hablar dentro del equipo recientemente; aún no tenemos planes concretos, pero nos damos cuenta de que sería una buena idea simplificar. Tal vez esto signifique que ya no usaremos virtual-hyperscript. El tiempo lo dirá.
La sintaxis es un poco extraña al principio. Recuerdo que me resultó muy confuso cuando empecé a escribir temas para Discourse, pero finalmente entendí cómo funciona. También es posible generar HTML crudo a través de un widget.
No soy el más experto para decir cuándo y dónde usar cada cosa, pero es una opción a considerar si estás haciendo trabajo personalizado, necesitas escribir un widget y tienes dificultades usando virtual-hyperscript.
¡Eso vale la pena saberlo, gracias! Pasé una hora o dos reescribiendo manualmente fragmentos de HTML, pero con esto y html2hyperscript, tengo un par de opciones para probar
Interesante… Pensé que una de las grandes ventajas de Ember era la velocidad de GlimmerVM. ¿El rendimiento de virtual-dom es una mejora tan significativa frente a Glimmer?
Entiendo. Esa cronología ayuda, ¡gracias! Así que, supongo que la opción más sencilla sería esperar hasta que el rendimiento de Glimmer sea equivalente al de virtual-dom, descartarlo y volver a Ember puro.
Esa función es genial, pero tengo algunos problemas para que funcione. He hecho require de discourse/widgets/hbs-compiler, pero aún obtengo el error: hbs no es una función
Tenemos algunas ideas en desarrollo sobre cómo racionalizar nuestros sistemas de plantillas. Investigaré este tema y te daré una respuesta a tu problema específico en los próximos días.
Sí. La transición podría ser un poco complicada. En principio, podríamos construir el equivalente inverso de html2hyperscript, pero en la práctica, la mayoría del hyperscript probablemente esté tan entrelazado con el JavaScript del widget, que podría convertirse rápidamente en una pesadilla.
Supongo que la solución más sencilla es mantener el soporte de hyperscript por un tiempo y, quizás, descontinuarlo más adelante.
Diría que, de hecho, todo lo contrario: haber racionalizado el uso de nuestras plantillas antes de Octane nos ayudará a migrar más fácilmente a la sintaxis de corchetes angulares cuando lo deseemos.
@edL Veo withPluginApi en tu stack trace: ¿estás intentando usar el compilador hbs dentro de una etiqueta <script> de un tema? Lamentablemente, el compilador de Handlebars para widgets no funciona en ese escenario.
