blog.bouzuya.net

2015-08-06 bouzuya/blog.bouzuya.net 3.3.1 をつくった & b-html の今後の展開 ほか

bouzuya/blog.bouzuya.net 3.3.1

[bouzuya/blog.bouzuya.net][] を 3.3.1 にアップデートした。

本文を表示できなくなるバグを修正した。

原因としてはサーバーからクライアントへ初期状態として渡している変数が script 要素に HTML コメントなしで含まれていたため。 </script> が本文に含まれている場合 (ツイートの埋め込みなど) に script タグが終了されてしまい以降の表示がおかしくなっていた。対応としては script 要素に HTML コメントを入れるようにした。これで上記の問題は発生しない。

今度は --> の問題が起きるような気がするので HTML エスケープを入れたほうが良かったかも……。

b-html の今後の展開

b-html (b-html/b-html) をどう展開するかを検討している。

CLI / HTML -> b-html converter / editor plugin / build tool plugin あたりは Issue にあるとおり進めていくつもりだ。検討したいのはそれ以外の部分だ。

そもそも b-html が必要な context や story は何かという点。

b-html の利用の前提

いくつか b-html を利用するための前提を挙げてみる。

  1. HTML やその fragment を書く
  2. オフサイドルールを好む
  3. 事前の変換を苦にしない
  4. ある程度の学習コストは苦にしない

これは例えば jade や jsx などの HTML 非互換のテンプレートを使っていないということだし、 CoffeeScript を JavaScript の代わりに使う感覚を持つということだ。

具体的なユースケースを挙げる。

CoffeeScript + AngularJS で SPA (Single Page Application) を開発している人に b-html は適している。AngularJS 1.x のテンプレートは HTML 互換である。つまり AngularJS のテンプレートのプリプロセッサとして b-html を使うことができる。CoffeeScript の変換を苦にしていないので b-html の変換も問題ない。

AngularJS を使っていれば ES6 (ES2015) + AngularJS でも可能だ。ES6 にはトランスパイラーが前提で Babel は事実上の標準になっていると言っていいからだ。CoffeeScript を拒否している理由がどこにあるかにもよるがオフサイドルールを理由としている場合は適用できない。

つまり AngularJS / CoffeeScript / ES6 (ES2015) で確認できる前提は次のとおりだ。

  • AngularJS で前提 1 「HTML」を満たす。
  • CoffeeScript で前提 2, 3 「オフサイドルール」「プリプロセッサ」を満たす。
  • ES6 (ES2015) で前提 3 「プリプロセッサ」を満たす。

前提の 3, 4 はすこし特殊だ。最近の JavaScript 環境ならプロプロセッサは標準なので問題になることは少ないし、学習コストについてはフレームワークに対しては許容できる可能性もある。そういう意味だと前提 1, 2 「HTML」「オフサイドルール」かもしれない。

他のケースはどうか。

  • Vue.js は前提 1 「HTML」を満たす。
  • EJS は前提 1 「HTML」を満たす (コード片を HTML のテキスト部分だと解釈すれば) 。
  • Handlebars は前提 1 「HTML」を満たす (プレースホルダーを HTML のテキスト部分だと解釈すれば) 。
  • Mustache は前提 1 「HTML」を満たす (プレースホルダーを HTML のテキスト部分だと解釈すれば) 。
  • React (JSX) は前提 1 「HTML」を満たせない (属性や JavaScript への埋め込みが問題) 。
  • jade は前提 1 「HTML」を満たせない。
  • haml は前提 1 「HTML」を満たせない。
  • slim は前提 1 「HTML」を満たせない。

前提 2 は精神的なものだとしても前提 1 を満たせないとそもそも導入できない。テンプレートエンジンが HTML 互換かどうかは極めて重要な問題だ。

真に前提と言えるものは「 HTML 互換」かどうかだろう。

b-html を適用できる例

対応できるものについては例を作成したほうが良いだろう。一方で jade / haml / slim は代替なので対応は要らないだろう。次の例はいますぐにでも作成できる。

上記はフレームワークをしないものがあるのでこれだけでも相当量の種類をつくれるだろう。

b-html を適用したい例

個人的には Virtual DOM 関連のフレームワークに b-html を適用したい。

一方で React / Mithril などの Virtual DOM 関連のフレームワークの多くはテンプレートエンジンを提供していなかったり JSX のように JavaScript と密に結合しているものもある。

これらに適用する場合は b-html に何かしらの拡張が必要になるだろう。

ただ個人的には React JSX の template と密に結合した構造は一長一短だと思うので template をロジックから可能な限り切り離したものが出てくる (既にある) と思う。JSX は EJS よりひどくコードと結合する。テンプレートというよりはコードの一部として機能する。

b-html を適用するためには mustache や handlebars のようにもうすこしコードを切り離した template にする必要がある。

b-html を拡張するのであればおそらく handlebars のようなアプローチで b-html+ (仮名) を JavaScript の template function に変換し、そこに data を流し込むイメージになるだろう。

React は String ではなく JavaScript の Object (React の Component) を要求するのでフレームワークに個別の変換が必要そうだ。

まとめ

b-html は AngularJS / Vue.js のような HTML 互換のテンプレートを要求するフレームワークには有効だが、最近の VirtualDOM を利用した React / Mithril / Deku / Riot のようなフレームワークでは適用が難しい。b-html をテンプレートエンジンとして使えるように b-html+ (仮) のように拡張する必要があり、その結果も各フレームワーク向けのものにすべきだろう。

react-b-html-plus ができる日も近いかもしれない。

参考

スプラトゥーン日記

スプラトゥーンが大幅にアップデートされた。

ランクの上限が 20 から 50 になり、ウデマエの上限が A+ から S+ になり、ブキ・ギアが増え、 BGM が増え、ルールが増え、ステージが変わった。

B → B

ルールはガチエリアでステージはモズク農園・タチウオパーキング。ブキはプライムシューター。ジャイロ慣れを進めている。

最初に連敗してその後は一進一退で大きな変化はなし。

つっこみすぎていたのを引くようにした。味方を常に自分の射程内にとらえておくことで射程をうまく活かせる距離で戦えるようになった気がする。

イカリング が追加されてフレンドとのランキングが見れるようになったのだけど、フレンドは 300 やら 400 なのに対して、ぼくだけがランキングスコアが 43 と 2 桁でひどかった。もうすこし勝てるように工夫しよう。