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]vs [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?

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 [29] Any idea why? I’m on 2.4.0beta5, and using theme-cli, if that helps.

I tried using templates within widgets but found it was of limited use without apparent support for helpers?: [image] Using a hbs file as the template for widget Development Related: Does this support helpers?, e.g.: Because I can’t get that to work if supplied as part of the template. 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:

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?

Is it worth waiting for Octane before investing further in this area? [image] Coming Soon in Ember Octane - Part 5: Glimmer Components (This post was originally published on www.pzuraq.com) Hello again, and welcome back! This is the fifth and final entry in the multipart Coming Soon in Ember Octane series, where we're...

Is it just me, or is Hyperscript hideous?

Development

j.jaffeux (Joffrey Jaffeux) October 23, 2019, 10:29am 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?

Topic		Replies	Views
Using a hbs file as the template for widget Development	3	1473	September 3, 2019
Modernizing inline script tags for templates & JS API Development dev-news	46	6276	March 25, 2026
JSX instead of h (createElement) function in widgets and other places Development	14	2164	May 10, 2020
Is it better for Discourse to use JavaScript or CoffeeScript? Development	54	67191	September 24, 2014
Deprecating .hbs file extension in themes and plugins Development dev-news	20	2272	August 9, 2026

Is it just me, or is Hyperscript hideous?

Related topics