Is it just me, or is Hyperscript hideous?

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
    01vs 56
  • 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!

Is it just me?

1 Like

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.

13 Likes

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.

8 Likes

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 :slight_smile:

1 Like

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 FEATURE: Use Glimmer compiler for widget templates · discourse/discourse@dffb1fc · GitHub

8 Likes

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.

14 Likes

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.

4 Likes

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

3 Likes

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.

3 Likes

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?
3 Likes

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?

1 Like

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.

11 Likes

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:

02

10 Likes

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

13 Likes

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

5 Likes