Hyperscript、僕だけ?あんなに醜いなんて。

ここで愚痴をこぼしますが、Jinja2、ERB、FTL、XSLT、JSX、Handlebars など、思い出すのも嫌になるほど多くのテンプレート言語を使ってきましたが、Hyperscript は本当に使いにくいです。

特に順序は付けませんが、問題となる点は以下の通りです:

  • コードの移植性(HTML スニペットをコンバーターに通さないとコピー&ペーストできない)
  • 構文ハイライト(すべてが巨大な塊になってしまいます)
    vs
  • コード補完は完全に壊れており、https://emmet.io のような時間短縮機能などは論外です。

PHP の悪い時代が恋しくなるなんて思わなかったのですが、Hyperscript がそれを実現しました!

これは私だけでしょうか?

はい、特に私たちが使っている Handlebars と比較すると、それが最も使いやすいとは言い難い点に同意します。Handlebars では、期待通りに HTML を記述できますから。

パフォーマンス向上が必要な箇所では、virtual-dom や virtual-hyperscript の導入を始めました。複数のテンプレートシステムを併用している現状については、最近チーム内で話し合うようになりました。具体的な計画はまだありませんが、単純化することが望ましいと認識しています。もしかすると、virtual-hyperscript は使わなくなるかもしれません。今後の経過を見守るしかありません。

構文は慣れるまで少し奇妙に感じるかもしれません。Discourse のテーマ作成を始めた頃は、私も最初は戸惑っていましたが、次第に仕組みを理解することができました。ウィジェットを通じて生 HTML を生成することも可能です。

いつ、どこで何を使うべきかを的確に説明するのは得意ではありませんが、カスタム作業を行っていてウィジェットを作成する必要があり、virtual-hyperscript の使用に困難を感じている場合は、検討すべき選択肢の一つです。

それを知る価値がありますね、ありがとう!私は1〜2時間かけてHTMLフラグメントを手動で書き直しましたが、これとhtml2hyperscriptの間で、試してみたいオプションがいくつかあります :slight_smile:

興味深いですね… Ember の大きな利点の一つは GlimmerVM のスピードだと聞いていたのですが、virtual-dom のパフォーマンスは Glimmer を大きく上回るのでしょうか?

Glimmer が可能になる前、私たちはすでに virtual-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と同等になるまで待ってから、Glimmerを廃止して純粋なEmberに戻すことでしょうか?

その機能は素晴らしいのですが、動作させるのに少し困っています。discourse/widgets/hbs-compilerrequire したのですが、まだ error: hbs is not a function というエラーが表示されます。

原因がわかる方はいませんか?

バージョンは 2.4.0beta5 で、theme-cli を使用しています。これが役立つかもしれません。

ウィジェット内でテンプレートを使用しようとしましたが、ヘルパーのサポートが明示的にないため、その有用性は限定的でした:

これは面倒でした。コードベース内の他の場所で既存の標準コードを再利用できないからです。

はい、残念ながら、現時点ではハンドルバーをハイパースクリプトの代わりに使おうとするのは、手間がかかる割にメリットが少ないと思います。

テンプレートシステムの合理化について現在ブレインストーミングを進めています。数日以内に、あなたの具体的な問題に対する回答を作成してご連絡いたします。

いいですね、ありがとうございます :slight_smile: その議論に参加できることを光栄に思いますし、他の形で貢献する方法を探すのも喜んでお手伝いします :slight_smile:

私たちが何を実現したいのかについての具体的な議論はありません。私たちが求めているのは完全な 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>MY TEMPLATE</p>
  `
});

[wrap] と WidgetGlue を使用した投稿での利用例:

@edL バックトレースに withPluginApi が含まれているのを見ましたが、テーマの <script> タグ内で hbs コンパイラを使用しようとしているのでしょうか?残念ながら、ウィジェット用のハンズバーズコンパイラはそのようなシナリオでは動作しません。

上記で @j.jaffeux 氏が示した import 文を使用して、ウィジェットを別のモジュールとして定義する必要があります。これは、マルチファイル JavaScript サポート を利用することで、テーマ内で行うことができます。

ああ、今わかりました。とても助かります!ありがとう、デビッド :slight_smile: