Eleventyファースト・インプレッション

• Welcome!/Home
• 楽屋裏話
• Eleventyファースト・インプレッション

Created at 11 June 2022, modified at 11 June 2022.

下記、4th.初代のリリース時の頃の駄文をほぼそのまま。

例えばJamstack.orgを一覧すればお分かりの通り、JavaScriptベースの静的サイト生成ツールは様々あります。
JavaScriptベースに限らず有名ドコロだと、何となくの印象的なトレンドで、Jekyllから始まり、HexoやHugoの時代が来て、今はGatsbyやNext.jsが熱いぜ、みたいな？

あくまで個人的な印象ですが、日本語情報が豊富に入手できるGatsbyやNext.jsではなく、何故に11ty/Eleventyにしたのか、ですが、「個人的に、取っつきやすかった」になります。
何とも曖昧な表現ですが、コレに限らず、数多のフレームワークって「相性」ってあるのではないかと。
何と言うか…打てば響く、ではないですが、分からなくても調べてそれを元に実装すれば「できた」となる達成感…学習曲線みたいな…

とは言うものの、結局の所、コンポーネント指向の波に乗り切れていないロートル・老害でしか無いと言えば実にその通りなのでありまして。
逆に言うと11ty/Eleventyは自分自身の過去の開発技法、ベースとなるページレイアウトを作り、それを継承/extendして…コンポーネント単位でincludeさせず（できますし、extendさせつつコンポーネントをincludeするのが普通かと思います。）、個々のページの変更点だけを書いていく、という手法ですね。
あ、いや、ReactやVueをベースにしたプロダクトもそうなのかもしれませんが、何故だろ…何かこう、しっくり来なかったと言うか…
だからと言って11ty/Eleventyはそういうロートル向けかとか、そういう議論を吹っかけるのマサカリは、やめて下さい…既に自分は死に体ですので、完全に無意味な行為です…

および、コレを書いている初稿の時点では実装していませんが、「11ty/eleventy×microCMSを使ったJamstackなサイトの作り方 - Qiita」とありますので、Jamstackを実装できるなら何でもいいや、非同期処理やキャッシュも使えるし、それよりも個別に管理画面を実装するの、面倒だしなぁ、というやや投げやりな理由もあります。

また、PHPベースの静的サイト生成も可能ではありますが、Sass/SCSSなども同時に触る必要があるため、だったら、Node.jsで統一した方がいいんじゃないかな、とも思いましたので、採用を見送りました。

多少補足しますと、割と本気でPHPのPico CMSでの実装をしていたり、取っつきやすさと相性が結構良かったと思いますが、更新が遅れているHarp.jsという選択肢もあるにはあったのですが、結局はEleventyを選択して今に至ります。

さて、前述を書いて以降に大きく変更した点の一つは、Netlifyへの展開ですね。
実は覚えていないのですが、ここに辿り着く以前は、Public用にビルドした生成物を自分が保持している（サブ）ドメインにFTPしていたのかなぁと。^[1]

ただし出力の自動化、GitHubからNetlifyへの自動展開は結構簡単にできましたが（サブドメイン割当やHTTPS化含め）、入力の自動化まではできていないのが現状ですね。
私自身は管理画面は不要ですが、仮にですけど、もしも仮にこれをPCに詳しくない方々が使う展開になった場合、さすがにコンソールベースでの運用は厳しいだろうなぁと想定されますので。

実はココは「ブログ」ではない、という認識

4th.二代目に関しての大きな変更点は、Eleventyを初めて触った昨年に比べ、Eleventyのフィルタの使い方、および、Nunjucksとの連動のさせ方が、以前と比べて何となく理解度が深まっていた点ですね。
具体的にはパンくずリスト生成など、Nunjucksをこねくり回すぐらいなら、フィルタを噛ませてしまえ、みたいな、これがJavaScriptのメソッドチェーンなのかと。

ところで少なくとも自分の中で、「このサイトはブログではない」という意識があります。

厳然たる定義までは調べていませんが、「ブログ」と言うと時系列に投稿を管理して、タグやカテゴリでコンテンツを管理する、だと認識しています。
それに対し、このサイトは時系列の管理に重きを置かず、章立ての文書を管理をしたい、というのがあり、割とCMSの考え方に近いのではないかと想像します。^[2]

となると、「親→子→孫→曾孫…」というコンテンツ管理をどうすれば良いか、が焦点になると考えます。
これを実装するのにEleventyのNavigationプラグインが良さそうに思いましたが、挫折しました。
実はこれはEleventy以前から、自分の中で長い間の課題でしたが、今回、ある程度実装できたかな、と実感しています。
それまでは実装に苦労していましたが、全く別のアプローチ方法をふと思いつき、仕組みとしては実に簡単な仕組みである、というハードルをクリアした事、そして次、具体的なJavaSciptの実装でつまづきそうでしたが、Eleventyのフィルタとして結構サクサクと実装できたかな、という実感です。

これはテストベンチに仕組みを簡単に説明しています。
理論的には「親→子→孫→曾孫…∞」まで可能な筈です…
ただ、Eleventyが望むであろう、提供しているタグやナビゲーションに背を向けてまで実装するべきだったのか、今も自分には分かりません。

テストベンチの作成

前述のNavigationプラグインや画像プラグインですが、今後、これらをこのサイトに取り込むために具体的に何かをする場合、テンプレートの実装やJavaScriptによる実装だけでなく、コンテンツやそのメタデータそのものも考慮する必要があると考えます。
これをこのサイトの今の状態で試すには危険で「重い」と感じたので（Git管理ではなく、単純にディレクトリコピーすれば良いとは言え）、別途、Eleventyをベースとしたピュアな状態…ゲームで言えばバニラな状態のEleventyが欲しいな、と思いました。
具体的には、毎回ゼロベースで.eleventy.jsの記述、ディレクトリ構成を整える、npmスクリプトを作り込むのも面倒だと感じたので作成した、になります。

そしてGitHubに上げてNetlifyと連動させて、と、ここまではいつもの自分のアクションですが、今回、せっかくなので本家サイトにもアプローチしよう、という色気を出しました。
ただ、実装がそれだけでは余りにも素っ気無さ過ぎるので、せっかくなので前述の「親→子→孫→曾孫…∞」も盛り込んでしまえ、が果たして良かったのかどうかは何とも言えませんが。
その結果として、Eleventyのソースコードサンプルに記載されています…と言うか、自分から登録申請しました。 ^[3]

で、これ、今までの自分だとそこまで…本家までアプローチしないと思うのですよ。
ところが今回、「稚拙なコーディングでも全世界に晒す」「100人の中で0.01人にでも刺さるモノであっても提供する」という気になったのは、何だろ、心境の変化ですかね。
自分、一応はプログラマを名乗ってますし、仮に完璧に理解してから（って具体的には何だろう）アプローチするのは遅過ぎる気がしましたので。

その結果、Eleventy界隈を見渡してみると、みんな凄いな、ですね。
なので凄い方々のエッセンスを取り込んでいければ、と思います。

蛇足

これは完全な蛇足ですが、自分の中で海外産のオープンソースプロダクトを日本語で紹介などを行う場合、日本語コミュニティを立ち上げる、これは完全な偏見でしょうけど、自分の中にそれがあります。
ですが自分には、その気は全く無いですし、もしも既に存在するならROMで参加はするかもしれませんが、という気分です。
むしろそれよりも、将来はEleventyを捨てて、コンテンツ生成は別のプロダクトに乗り換える時が来るかもしれない、という覚悟はあります。
ただし、YAML+Markdownで記述したコンテンツそのものは、新たなプロダクトに合わせたメタデータの変更を行い（場合によっては簡単なスクリプトを噛ませて）、使い回す予定です。

それで思い出しましたが、敢えて動的から静的サイト生成に舵を切ったのは、データベースを使いたくなかった、というのがあります。 ^[4]
大量にコンテンツを生成しない前提で、セキュリティなどの問題はさておき、平文のテキストファイルでコンテンツを管理したかったので。
もちろん、データベースでも都度、ダンプすれば可能なので、適所適材かと思いますが。