Back To Logs
devcareer

jQueryが現役のWeb制作チームにAstroを導入したら、割とハマった話

/System_Record

今いるWeb制作会社に入ったとき、コードはHTML・CSSで直書きでした。jQueryが現役で、フレームワークは使っていない。

「まあWebサイト制作なんでそんなもんか」と頭では思いつつ、実際に1ページごとにHTMLとCSSを書いていくのは、無理だと感じていました。コーポレートサイトって1ページが長いんですよ。それをページ数分繰り返していくのがしんどすぎて、泣きながら「お願いします、絶対こっちの方が早いんで」と頼んだのが最初です。

まず自分だけ許可をとった

最初から「チームでフレームワーク使いましょう」と言うのは角が立つかなと思ったので、「自分だけフレームワーク使って書いていいですか」という頼み方をしました。デプロイ先もCloudflareで自分が管理するから、という条件で許してもらって。Cloudflareを選んだのも、自分が普段使い慣れているからという単純な理由です。

その段階ではAstroを使い始めていたので、しばらくは自分だけAstroで書いていました。

ただ途中で「それ、あなたしか保守できないよね」という話が出てきて。確かに、と。SSGで出力しているのでHTMLファイルさえあればどうにかなるという意味では最悪ではないんですが、さすがにコードを誰も読めない状態はまずい。

そこで改めて「チームでAstroを使ってみませんか」という提案をしました。

なんでAstroだったか

最初に「フレームワーク入れるとしたら何がいいですか」と言われたとき、Next.jsは選択肢から外しました。自分がNext.jsあまり得意じゃないというのも正直あります。でもそれ以上に、このチームに渡すには複雑すぎると思った。

チームの大半がHTMLとCSSとjQueryしか触ったことがない人たちで、「コンポーネント指向」という概念自体が初めましての状態です。そこにいきなりNext.jsを渡して、Server Componentsってなんですかとか、use clientってどこに書くんですかとか、layout.tsxpage.tsxの使い分けは、みたいな話をしても多分最初の段階で嫌になる。

ちなみにNext.jsはAstroと同じくファイルベースルーティングなので、そこ自体は難しくないんですが、覚えるべき規約の数が多い。かといって生のReact(Vite)を渡しても、App.jsxにルーターを定義する書き方を最初から説明するのも、HTMLしか書いてこなかった人にはたぶん意味わからん感じになる。

Astroのファイルベースルーティングは、HTMLしか知らなかった人に説明するのが楽です。pages/about.astro を作ったら /about になる、というのはindex.htmlを作ってた感覚とそこまで遠くない。「ファイルの置き場所がURLになる」というのは直感的に入ってくる。

それとAstroはUIフレームワークへの依存を強制しない。ReactもVueも、Vanilla JSも書ける。既存のjQueryが絡んだ処理をいきなり全部Reactコンポーネントに直さなくていい、というのは現実的に大きい。スクリプトタグにそのまま書けるので、移行の粒度を自分たちで決められます。

コンポーネント分割できるようになったのが地味に良かった

HTML・CSSで書いていたころは、1ページに1HTMLファイル+対応するCSSファイルという構成でした。

これ、人間が読むだけでもつらいんですが、AIにコード生成させようとするとさらにつらい。「このページのヘッダー直して」と頼んだときに、関係するCSSがどのファイルにあるかを毎回説明する羽目になる。

Astroでコンポーネント単位に分割できるようになってから、AIとのやり取りがだいぶ楽になりました。「Header.astroを直して」と言えばいい。コードの文脈がコンポーネントに収まっているので、変更の影響範囲も読みやすい。

非エンジニアが修正するときも、コンテンツとレイアウトが分かれていれば文章だけ触ればいい、という状態にしやすい。

割とすんなり受け入れられた

正直、もう少し抵抗があるかなと思っていました。新しいものを覚えるのは面倒だし、今まで困っていなかったわけだから。

ただ「HTMLとCSSは今まで通りほぼそのまま書けて、ファイルの置き方のルールが増えた感じ」という説明が通じたのか、「まあやってみるか」くらいの温度感で受け入れてもらえました。

コーポレートサイトを作るだけなら、Astroはかなり過不足ないんですよね。サーバーサイドで複雑なことをするわけでも、状態管理が大変なわけでもないので。SSGで出力してCDNに置くだけ、という用途ではほぼ完璧に近い。

Next.jsを提案しなくてよかった、と今でも思っています。自分が苦手だからというのが半分ですが、このチームには合わなかったと思う。「チームが使えるかどうか」で選んでよかったです。

End_of_Record