GUIバージョンのGitbookの良さに気付いた
静的サイトジェネレーター(Static Site Generator。以下、SSG)についてのポエムです。
サマリ
- GUIに専念した
Gitbook
がSSGとして独自なポジションで、かつ、かなり万人向けなツールなんじゃ、、と言うポエム- もちろん、
Gitbook
ではダメだ、、と言うパターンもあるんだけど、、
- もちろん、
SSGメリット・デメリット整理
Gitbook
が、、と言うことを書く前に、まず、VuePress
Gatsby
Hexo
などのSSGと言われるツールのメリット・デメリットを、コンテンツマネジメントシステム(以下、CMS)との対比と言う文脈でザッとまとめることにします。
あくまでも、私見で抑えているレベルでのまとめですが、、
SSGのメリット
CMSが出回ってある程度した後、CMSのネックをカバー出来るツールとしてSSGは注目を集めます。主には3点かなーと。
- スタティックページを返すだけなので、パフォーマンスがCMSより良い
- CMSだと、リクエストのタイミングでビルドを走らせる
- コンテンツがユーザやページ上のアクション、入力パラメータに依らないため、インジェクション等されるリスクがCMSより小さい
- スタティックなページを返すだけなので!
- サーバ構築がDBや言語などを入れないとダメなCMSよりずっと楽
- SSGなら、ホスティング用のWebサーバを立てる、で大丈夫
SSGのデメリット
が、SSGになったことでCMSには無いデメリットも出てきました。
このうち、CMSではプラグインとしてカバーしていたのに、、と言う点は抜きにしちゃうと、SSGならではなデメリットは2点になるかなーと思っています。
- コンテンツをビルドして、ホスティングをする、をしないとページを公開出来ない
- ターミナルを立ち上げて
vuepress build docs
あたりを打たないといけない - と言うか、開発環境作りをしないとローカルでページすら出せない、、その点で非プログラマーにはハードルが上がった
- ターミナルを立ち上げて
- (プログラミング言語にも依るが)ツールのバージョンアップであっさりと死ぬリスクが高まる
-
Node.js
ベースのツールは特に食らうかも、とのイメージ
-
SSGはダイナミックなWebアプリケーション作りで行わないとダメなプログラミングを抜きにして、コンテンツがあればよしなにWebページの素になるリソースを作ってくれる点に良さがあるのですが、ビルドがCLIゆえに、プログラミングのバックボーンが無いことには走り出しが難しいことはダイナミックなアプリケーションと変わらず、、と言うことになってしまいました。
上の2点はいずれもプログラマーならばしょーもないデメリットなのですが、CMSではカバー出来ていた非プログラマーについてはこの限りでは無い、と言う具合ですね。
Gitbook
SSGのデメリットに "GUI" と言う回答をした そんな文脈上で、やっと Gitbook
の話をします。
Gitbook
は18年までCLI・GUIを並行して作っていましたが、GitHubのREADMEに大きく書かれているように、CLIはEOSになってしまいました。チームとして、GUIサイドに注力をします、と言うスタンスをぶち上げた、と言う訳です。
このスタンスに対して、社内・プライベートいずれでもCLIとしての Gitbook
を推していく!と立ち回ってきたかつての私のショックは大きかったですが、今ふりかえると、このスタンスによって Gitbook
は上記のSSGのデメリットに上手く回答をしたんじゃ、と言う具合に評価が変わってきました。
- コンテンツをビルドして、ホスティングをする、をしないとページを公開出来ない
- GUI上でドキュメントを書く、もしくはコンテンツだけメンテナンスしているGitHubリポジトリと連携してしまえばOKになった
-
Gitbook
は共有用のリンクやホスティング済コンテンツも用意してくれるため、コンテンツを作る人が非プログラマーであってもサクッと公開・共有が出来る
- (プログラミング言語にも依るが)ツールのバージョンアップであっさりと死ぬリスクが高まる
- プラットフォームのバージョンアップや後方互換性は
Gitbook
のメンテナンスチームの責として寄せられ、コンテンツを作る側は気にしなくて良くなった
- プラットフォームのバージョンアップや後方互換性は
Gitbook
のGUI化、と書きましたが、正しく書けばPaaS化なんだろう、と思っています。
ビルド・デプロイのために入れておかないとダメなツールなどは一式入れておき、ユーザに依存するコンテンツの中身だけは外からセットしてもらう、でスタティックなWebページを作れるようにしたのが Gitbook
です、と言う話なのかなーと。
そして、この点はツールとして提供を行う他のSSGと比べて、Gitbook
だけにある大きな独自性なのかな、とも思ったりしています。
Gitbook
はパーフェクトなのか
SSG全体のメリット・デメリットとして
上で書いたSSG全体のメリット・デメリットと言う点では、パーフェクトなのかなーと。
CLIで無くなりモヤモヤしているプログラマーもいるでしょう(私がそれを味わっていたので)し、CLIでプラグインを用いながらビルドを回していた人にとってもCLIのEOSはダメージが大きかったと思いますが、GUI単体をフラットに見た場合、Gitbook
は万人をカバー出来る、実に良いSSGだと思います。
Gitbook
と言うサービスが全シチュエーション対応の銀の弾丸なのか
PaaSとしてサービスを提供するスタンスにしたことが、その結論に大きく寄与したんじゃないか、と言う点は上記の通りです。
が、真にパーフェクトかと言われれば、PaaSになったことでいくらかかゆいけど手が届かない点が出てきたことも事実で、その点ではパーフェクトでは無いです。
- テンプレートを自在にいじれない
- テンプレートのオプションはいくつかあるが、レパートリーはOrganizationアカウントになっても4種だけ
- いじれると言っても対象はスタイルだけで、レイアウトは4パターン全て同じ。ライブラリのドキュメントページな仕上がりなので、SSGでブログを作る!と言う場合は
Gitbook
はNG
- テンプレート以外でもカスタマイズが出来るポイントは無くなった
- CLIでは用いることが出来たプラグインとか、、
- 閉じたネットワーク内での
Gitbook
運用が出来ない- セルフホスティングが出来る訳では無いので、例えば会社のネットワーク内で Gitbook + GitLab と言う取り合わせは出来ない
- Organizationを作ってプライベートアクセスにしてね、と言うことかもだが、会社ネットワークの外にコンテンツを置く、がホイホイとOKになるハズも無く、、
万人をカバーしたことのトレードオフとして妥当なポイントがザッと並んだイメージです。
Gitbook
の使い時
ホスティング先やコンテンツ管理先、Webページのデザインにこだわりが無いならば、テーブルに並べてあげる有力なツールかと思います。
- 技術ドキュメント
- 教材ドキュメント
あたりの、無機質なデザインでも大丈夫なドキュメントならば、Gitbook
はオススメしたい、と言うのが私見です。
デプロイだ、ビルドだを気にしないで、コンテンツ作りに注力出来るので、プログラマーであろうとなかろうとそのあたりのコストが無い分楽チンです。ほぼ、ブログを書くノリでWebページを作れます。
逆に、デザインへのこだわりを出したいページは、上記の通りカスタマイズはあんまり、、なので向かないイメージです。
- ブログ
- ポートフォリオサイト
ブログ用のテンプレートがたくさんあるSSGを用いて作っていく、と言う形でツールを決めていくと良いのかな、と思います。このあたりの優劣には疎いのですが、Hexo
になるんだろうか、、
まとめ
Gitbook
、CLIを止めたことへの賛否はあると思いつつ、私はGUIに絞って良かったんだろうなーと思います。
色々と制約事項はあれど、ツールとして、CLIとして提供されているライバルたちとは異なる土俵へ行き、従来のSSGのデメリットへ回答をしたGUIバージョンもナイスです。このあたりの戦略、狙っていたんだろうか、、タイミングがあれば1回聞いてみたいな。
何はともあれ、とりあえずGitHubアカウントがあればサクッとログインして遊べちゃうので、暇な時に遊んでみると楽しいかもしれないです!
参照した記事
-
【GitBook】 オンライン版とCLI版使ってみての比較|hiroaki|note
- CUI/GUIの
Gitbook
のメリット・デメリットがまとまっています
- CUI/GUIの
Discussion