大约何バージョン前、おそらく Next.js のバージョンを使用していた頃、私の記事の内容はlocal fileからSanity.ioという CMS に移行しました。
実際、Sanity.io は非常に素晴らしいですが、なぜ今また戻ってきたのか、ここで私はブログ開発の心の旅について話したいと思います。
Hexo 静的サイト#
ブログを構築する際、私はWordpressのような従来のウェブページ構築方法を選択しませんでした。一つはサーバーが必要で面倒だし、攻撃されやすいです。二つは、もう少しギークな方法が好きなので、静的生成のブログを選びました。
実際、過去の記事を見返すと、最初はHexoを使用していましたが、実際、この時期には一部の初期の記事が失われてしまいました😥。実際、Hexoは静的ブログプログラムとして非常に完璧で、基本的な機能はすべて備わっており、非常に良いコミュニティ環境もあります。
しかし、問題は私にとって、開発者として、Hexoのアーキテクチャが基本的には伝統的なテンプレート + CSS+JavaScript で構成されていることです。社会に出て働き始めた後、このようなアーキテクチャはもはや市場の需要ではありません。ウェブページの開発は、伝統的なテンプレートの構文 + CSS+JavaScript から徐々にVue、Reactなどのフレームワークに置き換えられています。特にVueは、新しくて古い体験を提供するため、国内では非常に人気があります。
そのため、ブログはReactを基にした静的生成フレームワークに向かいました。なぜVueではなく、まず、当時のVueベースのいくつかのブログプログラムは実際には使い物にならず、また、私の仕事では主にVueに触れる機会があり、余暇でもVueを使用することに興味が湧かなかったからです。
注：現在、Nuxt.js、Vitepress などを使用してブログを構築するのは非常に良い選択肢です。
React を受け入れる#
素晴らしい Gatsby#
最初に接触したのはGatsbyで、これはかなり古いウェブサイト開発フレームワークです。静的なブログを開発するためには、これは材料を過剰に使っていると言えますが、当時のソースコードは保存されていなかったので、少し残念です。これは私がReactをマスターした後の最初のプロジェクトです。
しかし、使用しているうちに、Gatsbyの重さが小さなブログには過剰すぎると感じました関連記事。当時、GitHub リポジトリに奇妙な依存関係の警告が表示されたため、後にNext.jsに切り替えました。
しかし、Gatsbyを使用することで、私は新しい知識であるGraphqlを得ました。ブログ内のデータ（記事など）はすべてGraphqlを使用してクエリする必要があり、これは当時のRestful、JSONrpcに触れた経験を広げるものでした。この部分の体験はまあまあでした。
次は誰？#
ReactエコシステムのトッププレイヤーであるNext.jsにたどり着きました。このフレームワークはReactをベースにしており、SSGの機能も提供しています。SSG\SSR\CSRという概念については、Gatsbyを使って知るようになってから理解しました。
ブログもこの時期にVercelに移行しました。以前はGithub Pageを使用していましたが、Githubが提供するGithub Actionを使って簡単な継続的インテグレーションを行いました。
ReactエコシステムのトッププレイヤーであるNext.jsは、欠点がほとんどないと言えます。この部分のブログのソースコードを見ると、後半ではローカルの markdown ファイルからSanity.ioにホストされたコンテンツに移行しています。リモートコンテンツを使用しながら完全なMDXエクスペリエンスを持つためには、かなりの努力が必要でした。その間、一時的にNotionを CMS として使用しようとしましたが、効果がなかったため、Sanity.ioに移行しました。
この時期、Reactのスキル向上に基づいて、Reactには確かにいくつかの心理的負担があることに気付きました。また、Next.jsのアーキテクチャ自体の不合理さもあります。単一ファイルのページシステムに基づいているため、Nodejs 環境と Web 環境が徐々に混同されてしまいます。Next.js 13 はApp Routerを導入し、この問題をある程度解決しました。喜ばしいことです
その後、一時的にvite-plugin-ssrに移行しました。
最速で最強#
Next.jsを使用している間、Viteが登場しました。本当に速くて便利です。webpackは本当に遅いし、プラグインの開発も面倒です。そのため、vite-plugin-ssrを使用してブログを構築することにしました。
正直言って、最初は少し手間がかかると感じました。以前は SSR フレームワークが開発者のために黙って行っていたことを再現するのは本当に大変でした。本当に泣きそう
そのため、しばらくの間をかけてvite-plugin-ssrを使用してNext.jsのブログを復元しました。実際、体験はかなり良いと思います。個人的には DX と UX の両方が一流だと思いますが、その後astroに出会いました。
宇宙時代#
フロントエンドの発展に伴い、目を見張るほど多くのフレームワークが登場しました。remix\Qwik\astroなどは、孤立したアーキテクチャをもたらすフレームワークとして非常に優れていると言われています。
私も流行に乗ってastroに参加しました。実際、astroについては、1.0 よりも前から接触していましたが、最終的には[email protected]がリリースされた時点で正式にブログをastroに移行しました。
astroは私にとっては本当に素晴らしいもので、直接HTML+CSS+JavaScriptを書くのと非常に似た体験です。多くの機能はネイティブの JavaScript を書くことで実現していますが、開発体験は非常にモダンで、Viteをベースにしており、完全なTypeScriptサポートも備えています。これは私に新しいものと古いものの両方の感覚をもたらしました。
また、各 UI フレームワークとの統合に基づいて、Vue、Solid、React をすべて組み合わせることができます。これは本当に素晴らしいと思います。私はastroが以前に使用していたすべてのソリューションにとって薄いカーテンであると思います。DX と UX の両方の面で。
また、この時期にSolidを知り、UI フレームワークとしてブログに組み込みました。Reactのような心理的負担がなく、レスポンシブ実装については、すでにReactのようなものはありません。また、フロントエンドのコンパイルはもはや欠かせないと思います。DX の一部を犠牲にして、パフォーマンスの向上などをもたらすことは非常に良いことです。
ただし、memo、useCallbackについてはよくわかりません。私の仕事ではあまりReactに触れることができないため、余暇の学習では本当に難しいものを選ぶべきではないと思います😥。おそらく React を使用する会社を探すべきかもしれません
記事の移行について#
実際、リモートの markdown コンテンツには完全な MDX エクスペリエンスがないため、またはランタイム 0JS を犠牲にすることを選択します、また、astroはコンテンツの統合においてははるかに優れた体験を提供しています。
また、Sanity.ioを使用すると、記事のワークフローが複雑になります。また、ギークなソリューションとして、git を基にしているので、次は記事をpush/pullしてリポジトリを移動させましょう。
Web3 への進化#
実際、最近xLogに出会いました。ブロックチェーン上のブログとして、ブログを書く必要がある方には、Web3 に足を踏み入れる最初のアプリケーションとしておすすめです。特にブログについてはあまり詳しくない方にとっては。
実際、Web 3 に関連する理論に関しては置いておいても、ブロックチェーン技術は私が考えるには、オープンで自由なインターネットの最も原始的な形態です。非中央集権化、検閲なし、合意に基づいています。
もちろん、人間の性質による悪意も充満していますが、特定の環境を望んでいる人や検閲されない書き込みプラットフォームが必要な人には魅力的かもしれません。