Is it just me, or is Hyperscript hideous?

Development

AI-generated summary

Discussion Summary: Is it just me, or is Hyperscript hideous?

The discussion revolves around the difficulties and frustrations of working with Hyperscript, a templating language used in Discourse. edL expresses their dislike for Hyperscript, citing issues with code portability, syntax highlighting, and code completion. awesomerobot agrees, sharing their experience of using virtual-dom/virtual-hyperscript for performance improvements.

Alternatives and Solutions

justin suggests using raw HTML via widgets as an alternative, providing an example code snippet. edL appreciates the tip and explores options for converting HTML to Hyperscript.

joffreyjaffeux mentions ongoing brainstorming to rationalize templating systems, with a goal of using full Handlebars (HBS) templates. edL cautions about the complexity of transitioning existing code, suggesting deprecation rather than immediate removal of Hyperscript support.

Technical Discussions and Examples

merefield shares their experience with using templates within widgets, highlighting limitations with helper support. joffreyjaffeux provides a detailed example of using HBS templates with widgets, and david clarifies the importance of defining widgets in separate modules.

joffreyjaffeux showcases a component using widgets and HBS, and merefield inquires about using existing helpers in widget templates. joffreyjaffeux explains that some helpers are available, and PRs for adding more are welcome.

Overall, the discussion highlights the challenges of working with Hyperscript and explores alternatives, solutions, and technical examples for improving templating in Discourse.

1

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
    01
    01654×148 4.1 KB
    vs
    56
    56606×118 9.52 KB
  • 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?

4

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.

5

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.

6

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:

7

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?

8

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

9

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.

10

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?

11

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

29
291282×334 62.5 KB

Any idea why?

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

12

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.

13

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

15

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.

16

Cool – thanks :slight_smile:

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

17

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?
18

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?

19

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

20

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.

21

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
02654×290 14.7 KB

22

@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 @j.jaffeux included above. You can do that in a theme using the multi-file javascript support.

23

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