Is it just me, or is Hyperscript hideous?

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 think we started using virual-dom before glimmer was a possibility? @eviltrout would know way better than I would.

This also reminded me that using handlebars in widgets using glimmer is possible… as of


Discourse is from 2013, we started complaining about Android performance in 2015, added virtual-dom in 2016, and Glimmer was announced in 2017 and it’s being actively integrated into Ember.


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

Any idea why?

I’m on 2.4.0beta5, and using theme-cli, if that helps.

1 Like

I tried using templates within widgets but found it was of limited use without apparent support for helpers?:

that was annoying as you couldn’t then re-use existing standard code elsewhere in the code-base.


Yeah, sadly, I think trying to use handlebars instead of hyperscript is currently more trouble than it’s worth.


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.


Cool – thanks :slight_smile:

I’d be happy to be part of that discussion and/or find other ways to pitch in :slight_smile:

1 Like

There s no real discussion of WHAT we want to do, we want full hbs. The question is more:

  • is perf good enough now?
  • how do we transition existing to this?

Aah… ok.

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?

1 Like

Is it worth waiting for Octane before investing further in this area?


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.


I will give a more detailed example in few days, but I can confirm it works.

import hbs from 'discourse/widgets/hbs-compiler';
import { createWidget } from "discourse/widgets/widget";

export default createWidget("foo", {
  template: hbs`
    <p>MY TEMPLATE</p>

Used in a post with [wrap] and WidgetGlue:



@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.


Oh, I see now – that’s really helpful! Thanks, David :slight_smile:


FYI I released a component few days ago which started as an example of what you can achieve with widgets and hbs:

Code is not perfect but you might learn a few things reading it.


@joffreyjaffeux thanks for that. I had a scan of the code and notice you extended things with ‘attach’ which is great.

Can you confirm it is not possible to use existing Helpers defined elsewhere in the app within a widget template?



you can use some of them, and it’s actually not that hard to add more, PR on this would probably be gladly accepted.

Starting point and list of available helpers are the list of cases in this switch:


Very useful! Thanks.