0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

TanStack Start × Tailwind構成を、Astro × SCSS構成に変えた話

0
Posted at

今回は、自分のポートフォリオサイトの構成を見直した話です。

https://tomo-site.page/

もともとは TanStack Start × Tailwind で作っていたんですが、Astro × SCSS構成にフルリプレースしました。

最初は、「流行りのTanStack Start!!」くらいの感じで TanStack Start × Tailwind 構成でポートフォリオを作っていました。

ちょうどAIを使った実装も増えてきていて、画面を見ながら「ここもう少し余白ほしい」「このカード並べて」「レスポンシブも対応して」みたいに指示を出していくと、かなり速いです。

Tailwindとの相性も良くて、とりあえず見た目を作るところまでは結構いい感じで作れるかなと思っています。

ただ、しばらく触っているうちに、だんだん気になるところが出てきました。

AIで作ると速い。でも後から読むのがしんどい

Tailwind自体が悪いという話ではないです。

むしろ、AIにUIを作らせるうえではかなり相性が良いと思っています。

ただ、自分の場合は後からコードを読むときがしんどかったです。。

<div className="flex items-center justify-between gap-4 rounded-xl border px-6 py-4 shadow-sm hover:shadow-md transition">

みたいなコードが大量に並んでいると、最初はそこまで気にならないんですが、画面が増えるにつれてかなり追いづらくなってきました。

特に気になったのが余白です。

親に gap があって、子に margin があって、さらに内側に padding があって、結果的には見た目として成立している。

でも、

「この余白って本当に必要だっけ?」

みたいなところが見えにくい。

AIに作ってもらうと、局所的にはちゃんと整えてくれるんですが、全体で見ると似たようなスタイルが少しずつ違う形で増えていたりします。

自分は共通化・そろえるの大好き人間なので、こういうところがものすごく気になるなと思う箇所が何度かありました。

自分で責任を持って書いていないコードが増える

たぶん自分がしんどく感じた一番の理由は、Tailwindというより、自分で責任を持って書いていないコードが増えたことでした。

AIに実装を任せると、完成までが本当に速いです。

ただ、そのぶん後からコードを見ると、

「なんでここに gap-4 が入ってるんだっけ」

「この mt-6 は必要だった?」

「この見た目、別のところとほぼ同じだけど共通化しなくていいのか」

みたいに、まず読み解くところから始まります。

もちろん、これはTailwindに限った話ではないです。

SCSSでもAIに全部書かせれば同じことは起きます。

ただ、自分の場合はTailwindだとスタイルがHTML側に細かく分散しているぶん、構成を理解して、自分なりに整理して、必要なら修正するまでに時間がかかると感じました。

見た目としては成立している。

でも「なぜこの指定なのか」が自分の中にない。

その状態で細かい余白やレスポンシブ、hover、状態ごとのスタイルまで追っていくと、思った以上に時間がかかります。

体感としては、最初から自分で考えながら書いたコードに比べて、理解して修正するまでに倍くらい時間がかかることもありました。

なので、今回しんどかったのは、

Tailwindだから読めないというより、AIで高速に作ったTailwindを、あとから自分のコードとして理解し直すコストが高かった

という方が近いです。

そもそもTanStack Startが必要だったのか

もうひとつ見直したのが、フレームワーク自体です。

このサイトの基本構成は、

  • 制作実績
  • ブログ
  • プロフィール
  • お問い合わせ

くらいです。

そう考えると、Astroの方がかなり素直でした。TanStack Startだとちょっとオーバースペック。

Reactが必要なところだけ使えるし、ページ全体をReactで持つ必要もない。

自分のポートフォリオにはこっちの方が合っていました。

Astro × SCSSに変更

最終的に、

TanStack Start × Tailwind

から、

Astro × SCSS

に変更しました。

変更して一番良かったのは、単純にコードが読みやすくなったことです。

HTMLはHTMLとして読めるし、スタイルはSCSS側で追える。

コンポーネントごとにスタイルをまとめておけば、

「この見た目はどこで決まっているんだろう」

と探し回ることも減りました。

AIにコードを書いてもらうときも、

「このコンポーネント用のSCSSとしてまとめて」

みたいに指示することが増えました。

個人的にはこの方が、生成されたコードを後から確認しやすいです。

AIに書いてもらうこと自体はやめていません。

むしろ、これからも普通に使っていくと思います。

ただ、生成速度だけではなく、あとから自分が責任を持って触れる形になっているかは意識するようになりました。

結論

  • TailwindなどのCSSフレームワーク:自由にスタイリングしながら、スピード重視で作るときに向いている
  • 素のCSS / SCSSで組むやり方:規則性や細かいこだわり、保守性を重視したいときに向いている
  • Next.jsやTanStack Start:複雑な状態管理やインタラクションが多い、管理画面・WEBアプリ向き
  • Astro:コンテンツ中心で、必要なところだけ動的にしたいサイト向き
  • フルバイブコーディングなら、TailwindなどのCSSフレームワークとの相性はかなり良い

なので、どれが良いというより、作るものや運用に合わせて選ぶのが良さそうという結論です。

今回のポートフォリオでは、長く触ることも考えて、複雑なアプリケーション構成やCSSフレームワークに寄せるより、Astro × SCSSで自分で構成とスタイル設計を持つやり方の方が合っていました。

そんな理由で、今回はAstro × SCSSに変更しました。
技術選定などの参考になれば幸いです。


元記事はこちら

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?