Just venting here, but having used more templating languages than I care to remember (Jinja2, ERB, FTL, XSLT, JSX, Handlebars, etc), I find Hyperscript utterly horrid to work with.
In no particular order, the things it breaks include:
Code portability (can’t copy/paste html snippets without running them through a converter)
Syntax highlighting (turns everything into a huge blob) eg vs
Code completion is FUBAR, let alone time-savers like https://emmet.io
I never thought anything would make me pine for the bad old days of PHP, but Hyperscript’s done it!
Yeah I agree that it’s not the best to work with, especially compared to handlebars (which we also use) where you can write HTML as you’d expect.
We started using virtual-dom/virtual-hyperscript in places where we needed to improve performance. The topic of our multiple templating systems has been something we started talking about within the team recently; we don’t have any concrete plans yet, but realize it would be a good idea to simplify. Maybe this means we won’t use virtual-hyperscript anymore? Time will tell.
The syntax is a little weird to get used to. I remember being really tripped out by it when I first started writing Discourse themes, but I eventually figured out how it works. It’s also possible to generate raw HTML via widget as well.
I’m not the most skilled at being able to say when to use what and where, but it’s an option to consider if you’re doing some custom work, need to write a widget, and are having difficulty using virtual-hyperscript.
That’s worth knowing – thanks! I spent an hour or two manually re-writing html fragments, but between this and html2hyperscript, I’ve got a couple of options to play with
Interesting… I thought one of the big benefits of Ember was the speed of the GlimmerVM. Is virtual-dom performance that much of an improvement over Glimmer?
I see. That timeline helps – thanks! So, I suppose the easiest course would be to wait until Glimmer performance is equivalent to virtual-dom, then dump it and revert to pure Ember?
That feature is cool, but I’m having some trouble getting it to work. I’ve require'd discourse/widgets/hbs-compiler, but I still get error: hbs is not a function
We have some current brainstorming on how to rationalize our templating systems. I will dig into this and make you an answer to your specific issue in the next days.
Yeah. The transition could be a bit thorny. In principle, we could build the reverse equivalent of html2hyperscript, but in practice, most hyperscript is likely to be so intertwined with the widget’s js, that it could quickly become a nightmare.
I suppose the simplest solution is to retain hyperscript support for a while, and perhaps deprecate it down the line?
I would say quite the opposite in fact, having rationalized our template usage before octane, will help us to migrate to angle bracket syntax more easily when we want to.
@edL I see withPluginApi in your backtrace - are you trying to use the hbs compiler inside a theme <script> tag? Unfortunately the widget handlebars compiler doesn’t work in that scenario.
You need to define the widget in a separate module using the import statements which @joffreyjaffeux included above. You can do that in a theme using the multi-file javascript support.
vs 
