人がなにかを作るときは何かしらの選択が伴っている.言語はどうするとかフレームワークはとか,コンポーネントの配置はどうするとか. この記事では,当ブログの構築で俺が行ってきた選択を振り返っていきたい.将来なにかに役に立つはず.
フレームワーク (Gatsby を選んだ理由)
このブログはGatsby.jsを使って構築されている.React を使う静的サイトジェネレータで,
適当に src/pages
に JSX/TSX ファイルを置くと勝手にページができてルーティングが組み上がる.
豊富なプラグインを npm で引っ張ってきてgatsby-config.js
に書けば Babel や webpack の設定をいい感じでやってくれたり,
データを GraphQL で引っ張ってコンポーネントで使えるので楽.
楽な代わりに webpack の使い方がわからなくなる罠があってだな…
ともかくとして静的サイトを Netlify とかにぶん投げるのには向いている (というかそのためにある) ので,個人のもつブログだったり,他の React 系 OSS のドキュメントだったりによく使われている. React 系どころか React の公式が Gatsby だったり,最近新しくなったらしい TypeScript の公式も Gatsby だったり,すげーとなるようなところでも登場する.
ブログフレームワークを使わなかった理由
ブログ作りでいえば,静的サイトジェネレータから一歩踏み込んだブログフレームワークの類い—Node.js なら Hexo—を使うという選択肢もある. なぜ Hexo を使わなかったのかというと 速くない,JSX できない,なんか面白くない という理由による.
Hexo なら適当にえーいってやればそれっぽくブログが完成してしまうのだが,逆に Hexo がなんでもやってくれるんで細かいカスタムが面倒. React じゃないので EJS だの Pug だの標準外のテンプレート言語を学習して学ばなければいけなかった.それ,JSX でよくね? そんで,気に入ったテーマ,具体名を挙げると Tranquilpeak なのだが,このテーマのライセンスが GPL で, これを使ったサイトは GPL にしなきゃいけないのか気になって夜しか眠れなくなったので Hexo ごとやめた.
他のブログフレームワークといえば Hugo か Jekyll だろうが,Golang も Ruby も宗教上相容れなさそうだと感じたので選択肢にすら入れてない. ちょっと思ったことだが,ブログフレームワークはブログを作るためのもので,利用者の目的はブログに 記事を書いて 公開することだ. それに対してフロントエンド界隈でブログ作るのが流行っているのは ブログそのものを作ること を目的にしている感じがあるのではないか. 自分は後者側 (になりたい) なので,ブログフレームワークを使ってもあんま面白くないな~と思ったのも Gatsby を選んだ理由.
Vue 系 (Nuxt とか VuePress とか?) を使わなかった理由
Vue 使ったことない.最近 Vue3 出たけど初心者向けドキュメントとかまだあんまなさそうなので入門するモチベーションもまだそこまで高くない. だいたいゲームチェンジ的な機能が入った直後というのは既存開発者向けに「ここが変わった!!ここが革新的!!」というのを紹介する記事が多くて, 初心者は一旦古いほうを学んでから学び直す必要があると思う.うろ覚えだけど React のチュートリアルも Hooks 対応完了してたっけ?もしかしてまだじゃなかった?
Vue 自体には React との差分を見て知見知見したいという興味がある.今はまだ時期じゃないんじゃないかと若干思っているだけ. もしかしたら Composition API もまるごと入った新しいチュートリアルがもう用意されてたりするのかもしれない…
Gatsby 以外の React 系 (というか Next) を使わなかった理由
使ったことないが,Gatsby のがブログ作りに寄ってそうなので Gatsby 使った.Next でも近いうちになにか作りたい.
デプロイ先 (Firebase Hosting に置いてる理由)
本ブログは Firebase Hosting にデプロイしている.それはなぜかというと,Netlify が日本に CDN 鯖を置いてないので本邦からのアクセスが遅いという風のうわさを聞いたからである. 結論から言っちゃうと.Firebase がそんな Netlify と比べて早いってことはない ような気がする.これは Gatsby の超速性に由来するものであろう(該当記事は Gatsby の話はしてない). あと本ブログが画像を扱わないせいもあると思う.
結果的には Firebase を使ってみて Netlify の簡単さがわかったのでよかったと思っている.GitHub 連携して push するだけ. Firebase Hosting にそんなものはないので GitHub Actions での自動デプロイをやってみたけどわりと楽しい.GitHub Actions 便利.
まあ,そのうち (読む人が増えて無料プラン上限にぶち当たったりしたら) Netlify に戻すかもしれない.そんな日は来ないと思うが.
Tailwind/Emotion にしてる理由
CSS フレームワークは Tailwind,CSS in JS ライブラリに Emotion を使っている. Tailwind で細かめなスタイルをじゃかじゃか書き,複雑なスタイルは Emotion で書く,というスタイル.
なぜこのコンビかというと,「HTML-CSS-JS 分離なんてもう古いぜ!時代は全部統合してコンポーネントで分割だよな!」
という フロントエンドエンジニアの悪いところとしてはてなブックマークでよく揶揄される ミーハー心からである.
このへんに styled-components を使わなかった理由があって,あれ styled(HogeComponent)
の形でしか書けない (よな?) のでちょっと冗長だなと思って使ってない.
そしてミーハー心により後発のライブラリを使いがち.
ちなみに Gatsby で Tailwind を使うには 2 種類の方法があって,ひとつが PostCSS を使う方法,もうひとつが Babel マクロで CSS-in-JS ライブラリ (Emotion) と使う方法.
このブログでは両方使ってて,たとえば <div className="pt-2"> ...
というようなのは PostCSS での適用方法 (だよな?).
これが Tailwind のスタンダードな使い方で,JSX で要素を書くのと一緒にバーっと書ける.
それに対して Babel マクロ (Twin.macro) では,CSS-in-JS ライブラリでスタイルを作るテンプレート文字列になんかマクロを埋め込んで Tailwind を混ぜ込める.説明が難しいけどこんな感じ.
export const h1Style = css`
h1 {
${tw`leading-snug mb-3 mt-8 text-3xl border-b border-border`};
font-feature-settings: "palt";
}
`;
これのいいところは直接 JSX を書かずともスタイルを適用できるところ.たとえば gatsby-plugin-autolink-headers が生成するリンクとか, 記事内のすべての h1 要素とかにはネストやクラス指定が必要になる.そんなときにはこいつで埋め込めば OK.
Tailwind の VSCode 拡張を入れればクラス名の補完を (tailwind.config.js
を読んで) 出してくれるし,
styled-components の拡張を入れれば CSS-in-JS のテンプレート文字列もしっかりハイライトしてくれる.
こいつらがクソ便利なのだが,補完についてエディタ拡張に頼るというのになんとなく気持ち悪さを感じているのは俺だけではないはず.
いやでも CSS なんてそんなもんか.
MDX を使う理由
MDX というのは JSX の Markdown 版みたいなもんである.つまり Markdown の中に <Niconico src="sm9" />
とか書いて React コンポーネントを埋め込める.
すごい!どうやってるのか全然想像もつかん.
中身がどうなってるのかは想像できないがとりあえず YouTube 埋め込みとかがさらっとできて便利だったりするのでこれでいいやと思っている.
そして各種 GraphQL クエリが MDX 前提になってて gatsby-transformer-remark
に変えたときの処理が面倒という理由も…
デザインについて
デザイン不慣れなので,padding とかの大きさとかは Tailwind のデフォルトを使いまわしてる. 初心者に選択肢を与えすぎると辛いことになるので,いい感じの縛りを享受することで苦痛を軽減しているのだ.
カラーリングは Tailwind のデフォルトから変えることにした.背景色とか文字色その他に使うグレーは青寄りの紫,アクセントカラーはほんの少し紫に寄った赤ピンク.
順番としてはアクセントが先で,こういう色合いが好きだったのでそのまま使ってみた.それと近めでかつ青に寄っている紫をグレーとして清涼感を醸し出す (出てほしい).
結果的にこんな感じになったが,なんとなくお菓子っぽい感じになった.ケーキとか Cookie クッキーとかではなく,なんというかハイチュウとかキャンディとかそういう方面のお菓子.
そうそう,それと TableOfContents (目次) が左に置いてある. Qiita や Zenn など ToC を右に置くデザインが多数派を占める中なぜこうしたかというと,なんとなく左にあったほうが落ち着くような気がするから. そういえば筆箱を左に置く癖があるので,ツール類を左に置きたいのだろうか.
まとめ
「理由」がゲシュタルト崩壊した.なぜって?この記事を書いたからだよ!