2017年11月4日（土）ベルサール半蔵門 イベントホールで開催したCSS Nite LP54「Coder's High 2017」のフォローアップとして、中村 勇希さん（トゥーアール）『テンプレートエンジンPugを使った、みんなでやるウェブ制作』セッションのスライドなどを公開します。
フォローアップメッセージは、イベント開催直後（2017年11月）の時点のものです。
フォローアップメッセージ（補足など）
「テンプレートエンジンPugを使った、みんなでやるウェブ制作」のセッションを担当した中村です。セッションをご覧いただきましてありがとうございました。
今回のお話は「ツールの紹介」といった側面と「コーディングをデザインの一環として捉える」といった側面がありました。アンケートやTwitterをコメントをみていると、コーディングがデザインを言語化することであることについて共感・実践してみたいというコメントを頂けているようで幸いです。
一方で、運用の面で課題が多いのも事実です。特に、新規案件や、個人的には取り入れていきたいものの、実務で役立てられるかどうかという点では厳しそうというコメントも多くいただきましたので、こちらで回答いたします。
ツール
ejsはどうなの？
できることについては、Pugとそんなに変わりません。決定的にこれができないので採用できないということはなく、私もejsを使うことはあります。
# メリット
- HTMLをそのまま書くことができる
- Sassにおける「scss記法」的なもの
こちらは「Pugさすがにキモいもののコンポーネント指向で考えたい」という人はこちらの導入をおすすめします。こちらも中にJavaScriptを埋め込むことができます。Pugのように-と書くだけでJavaScriptにはならず<%%>のようにする必要があり、PHPのような見た目になります。
ejsとPugの混在はできるか
中間成果物としてのHTMLを生成し、それらをどちらかで読み込むという形になるかと思います。そうすれば、混在させることは可能です。ですが、オススメはしません。記法が混在し、コンパイルも二重に必要で、結局どちらつかずになってしまうでしょう。
現状ejsで動いているものをPugで扱いたい場合、一旦EJSをHTMLにコンパイルし、HTML2Pugなどを用いてPugに直してしまうという手もあります。
izolate/html2pug: Converts HTML to Pug
ブラウザ版もあります。
html2pug - convert your html code to jade
運用
エンジニアがいないと難しいか
環境面でいうと、何か問題があったときにメンバー全員が「黒い画面怖い」みたいな状態だと立ち往生してしまうかもしれません。最低でも一人は「少しわかる」みたいな人がいるのが理想です。
しかし、その状態ではSassも満足に導入できないという悩みもあるかと思います。少しセッション後にお話しましたが、現在その辺を含めた「デザイナー・新米コーダーでもフロントエンド怖くなくなる」ような書籍を執筆しておりますので、そちらをお待ちいただければと思います。
[宣伝]gulpに関しては、こちらの書籍をご参考いただければと思います。
ゼロからはじめるgulp入門書 - nayucolony - BOOTH（同人誌通販・ダウンロード）
コンパイル後のHTMLを触られてしまう
解決しようとする場合、社内外のコミュニケーションの部分から始まりますが、それが行き届かない範囲も関与する形になってしまうと、運用までPugでやるのは難しいです。
ツールで無理やり解決しようとするならば、HTML2Pugを使って差分をとって……という手段もなくはないのですが、あずかり知らないところで改変されているという場合は先祖返りしてしまうので有効ではないでしょう。そういう体制の場合、Pug云々のまえにまずはGitの導入からはじめることをおすすめします。Gitはセーブポイントです。
Pugを使いたい場合、初期開発だけPug、運用体制に入ったらHTML、というのが妥当なところです。初期開発だけでも、共通化などでPugは役立つ部分が多いので、ぜひ活用してみてください。
また、例えばトップページのメッセージを変えるなどで、あらかじめ他者によるHTMLの修正があることがわかっているのであれば、その部分だけをコンポーネントとして区切っておき「このファイルのテキストだけを変えてください」という取り決めをしておくと良いのではないかと思います。コンパイル作業は、コンパイル用のコマンドをバッチファイル化しておけばワンクリックでOKです（前川さんのセッションを参考にしてください）。
ファイル管理が大変そう
コンポーネントと呼べるものが増えれば増えるほどファイルが増えていきます。これらは、セッション中でもお話した通り、CSSと同じ粒度で同じように管理していくのが理想です（こうなってくると、CSS設計論的な話になっちゃうのですが）。Pug側で好き勝手にファイル管理の方法を生み出したところで、CSSとの関係性がわかりにくくなってしまっては、プロジェクト全体において「ファイル管理が大変」であることが解決できません。
一つのアプローチとして、CSSフレームワークのファイル管理方法を眺めて見ることをオススメします。案件全てに同じ考えは通用しなくても、どのくらいの粒度、どのくらいのカテゴリ感で管理しているかの参考になりますよ。
bulma/sass at master ? jgthms/bulma
bootstrap/scss at v4-dev ? twbs/bootstrap
スキルレベルによっては共有が難しそう
Pug記法がわからない、という点では、今まで見たことがない新しいものである以上仕方ない部分があります。
また、Pugで使うプログラミング的表現は「if」「else」「case/when」「include」などで、プログラムを書いているというよりは英語でコメントをしているというものに近いです。ですので、すでにJavaScriptの知識がないと使えないというものではありません。「言語化」という目的を忘れずに、なるべくシンプルを心がけましょう。
どうしてもシンプルにできない場合、そもそもデザインが複雑すぎるという可能性もあります。言語化をしているときに、もっと妥当なデザインアプローチが見つかるかもしれません。デザイナーと相談してみることも一つの解決方法です。
他人の書いたPugがわからない問題
なまじプログラミングができちゃう人ががっつりプログラミングしてしまうということはあります。それが必要なものであればいいのですが……
今回のセッションは、プログラムを書いてカッコよくやろうという話ではありません。例えば二つパターンがあったときに、ただ単に二つのファイルを渡すよりも、一つのファイル内で「こういうときはA、こういうときはB」と書いた方が、よりコードに「意味」が出てきていいよね、というお話でした。ですので、書くときは「プログラミング」というよりは「言語化」という部分を意識してほしいと思います。
PHPを中にかけるか
YesかNoかでいうと、Yesです。PHPを「プレーンテキストとして書き出させる」ことでHTML内にPHPを書き出すことができます。PHPで分割したファイルの挿入も繰り返しもできてしまうので、PHPが使える環境でPugで頑張る必要はないかと思います。
コンパイルの短縮
gulpをお使いでしたら、gulp-changedやgulp-cachedを用いることで一部改善できます。
sindresorhus/gulp-changed: Only pass through changed files
contra/gulp-cached: A simple in-memory file cache for gulp
全ページに挿入されているファイルの変更を行なった場合はやはりページの数だけコンパイルする必要があります。こればかりはコンパイラの処理速度に依存してしまうためです。しかし、素のHTMLで同じことをしようとした場合に人力でそれよりも早く処理を終えることができるのか？検索置換を行なった場合、正確に完了できるのか？ということも加味すると、割り切ってもいいのではないかというのが個人的な意見です。
jsonでデータを連携させる際のうまいやりかたが知りたい
Pug及びNode.jsはサーバサイドの技術です。テンプレートとデータに分けて考えるやり方は独自性のある考え方ではなく、サーバサイドですでに行われている手法です。ですので、データベースやAPIの設計論を参考にしてみてください。オープンソースなWordPressテーマの作りを眺めて見るのもよさそうです。いろいろなデザイン（＝設計パターン）が見えてきますよ。
また、デザインでいうと、インフォメーションアーキテクチャの考え方が流用できる部分もあります。いろいろな世界の「情報の取り扱い方」を組み合わせて、プロジェクトに適切なデータ設計を行なってみてください。
その他
div使いすぎ
ごめんなさい、アンチパターンでした。私はインブラウザデザインでのワイヤーフレーム作成を行うことが多く、その際にCSSフレームワークの「Bulma」を使っています（全ソースコードを写経した経験もあります）。プロトタイピング目的ではdivで十分なので、ついあの場で手癖が出てしまいました。もちろん、実装ではちゃんとやってますよ！
Bulma: a modern CSS framework based on Flexbox
[宣伝]古いバージョンですが、コードリーディング本もあります。
Bulma Code Reading ~ フレームワークから学ぶCSSテクニック - nayucolony - BOOTH
Butjon
Microsoftの「Fabric」の紹介で触れた「Butjon」
よくよく考えると、Microsoftのプロジェクトでそんなことあるか？と思い、あの後、GitHubで次のようなプルリクエストを投げつけてみました。
replace butjon
/ button
by nayucolony ? Pull Request #3309 ? OfficeDev/office-ui-fabric-react
返ってきた回答は「ディセンダーを含めて見た目をチェックをするために意図的にいれています」というような内容でした。ディセンダーとは、文字のベースラインを下側にはみ出す部分です。「j」「g」なんかがそうですね。知りませんでした。
これをみて、また一つ知識が増えました。皆さんも「ディセンダー」を意識してみてください。
このセッションは「CSS Niteベストセッション2017」にて新人賞に選ばれました。
ベストセッション2019
2019年、CSS Niteでは49回の関連イベントを通して123セッションが行われました。その中からベスト・セッション＋αを選びました。
