只是在这里发发牢骚，但用过的模板语言多得我自己都记不清了（Jinja2、ERB、FTL、XSLT、JSX、Handlebars 等等），我发现 Hyperscript 用起来简直糟透了。
按随意顺序，它带来的问题包括：
我从未想过有什么东西会让我怀念 PHP 那段糟糕的旧时光，但 Hyperscript 做到了！
难道只有我这么觉得吗？
是的，我同意它并不是最理想的工作方式，尤其是与 Handlebars（我们也在使用的模板引擎）相比，后者允许你按预期编写 HTML。
我们在需要提升性能的地方开始使用 virtual-dom/virtual-hyperscript。关于使用多种模板系统的问题，我们团队最近才开始讨论；目前还没有具体的计划，但我们意识到简化是一个好主意。也许这意味着我们将不再使用 virtual-hyperscript？时间会给出答案。
语法有点奇怪，需要时间适应。我记得刚开始写 Discourse 主题时，曾被它搞得晕头转向，但后来我终于搞懂了它的运作方式。此外，也可以通过 widget 生成原始 HTML。
我不太擅长判断何时何地该用什么，但如果你正在进行一些自定义开发、需要编写 widget，且在虚拟 hyperscript 的使用上遇到困难，这是一个可以考虑的选项。
这很有价值——谢谢！我花了一两个小时手动重写 HTML 片段，但现在有了这个工具加上 html2hyperscript，我有了几个可以试试的选项 
有意思……我曾以为 Ember 的一大优势在于 GlimmerVM 的速度。难道 virtual-dom 的性能比 Glimmer 提升如此显著？
我认为我们在 Glimmer 成为可能之前就开始使用虚拟 DOM 了？@eviltrout 比我更清楚。
这也让我想起，在 Glimmer 中于组件内使用 Handlebars 是可行的……具体可参考：FEATURE: Use Glimmer compiler for widget templates · discourse/discourse@dffb1fc · GitHub
Discourse 始于 2013 年，我们在 2015 年 开始抱怨 Android 性能问题，于 2016 年 引入了 virtual-dom，Glimmer 在 2017 年 被宣布，并正在积极 集成到 Ember 中。
明白了。这个时间线很有帮助——谢谢！那么，我想最简单的做法是等到 Glimmer 的性能与 virtual-dom 相当后，就弃用它并回退到纯 Ember？
我尝试在部件中使用模板，但发现其用处有限，且似乎不支持辅助函数：
这很令人烦恼，因为这样一来，您就无法在代码库的其他地方重用现有的标准代码。
是的，很遗憾，我认为目前尝试用 Handlebars 代替 Hyperscript 弊大于利。
我们目前正在就如何优化模板系统进行头脑风暴。我会在接下来几天深入研究，并针对您的具体问题给出答复。
太棒了——谢谢
我很乐意参与讨论，或者以其他方式帮忙
我们并没有真正讨论想要做什么，我们想要完整的 HBS。问题更多在于：
啊……好的。
是的，过渡可能会有些棘手。原则上，我们可以构建 html2hyperscript 的逆向等价工具，但实际上，大多数 hyperscript 很可能与组件的 JavaScript 代码紧密交织，这样很快可能会变成一场噩梦。
我想最简单的解决方案是暂时保留对 hyperscript 的支持，并可能在将来逐步弃用它？
在进一步投资该领域之前，等待 Octane 是否值得？
我反而认为，在 Octane 之前对模板使用进行合理化，将有助于我们在需要时更轻松地迁移到角括号语法。
我将在几天内提供一个更详细的示例，但我可以确认它确实有效。
import hbs from 'discourse/widgets/hbs-compiler';
import { createWidget } from "discourse/widgets/widget";
export default createWidget("foo", {
template: hbs`
<p>我的模板</p>
`
});
在帖子中与 [wrap] 和 WidgetGlue 一起使用：
@edL 我在你的堆栈跟踪中看到了 withPluginApi——你是在主题的 <script> 标签内尝试使用 hbs 编译器吗？不幸的是，widget Handlebars 编译器在这种场景下无法工作。
你需要使用 @j.jaffeux 在上面提到的 import 语句，在单独的模块中定义 widget。你可以在主题中通过 多文件 JavaScript 支持 来实现这一点。
哦，我明白了——这真的很有帮助！谢谢，David
