Share
Embed
MTDDC Meetup TOKYO 2023
MTDDC Meetup TOKYO 2023の登壇資料です。
「CMSを取り巻くフロントエンド開発の現状と課題」
Chinen
November 11, 2023
Transcript
41 slides
-
株式会社TAM/TAMTO:フロントエンドエンジニア 兼 個人事業主 知念 昌史 / まぁし X(Twitter)@chocodogmagic • 職歴:大学卒
→ 美容師 → エンジニア12年くらい • 2019年に東京 → 沖縄へ帰省してフルリモート(沖縄在住) Vue.js/Nuxt/Jamstack/セマンティックなHTML/PWA/ アクセシビリティ/SEO/パフォーマンス改善/Movable Type -
個人的な活動 • 平日9:00〜朝活配信:おはようエンジニア #ohayo_engineer ◦ X(旧Twitter)SpacesでWeb関連の情報発信中、フォローしてね ◦ 550回継続しているがいまだに早起きは苦手、一緒にがんばろ? • コミュニティ運営
◦ PWA Night(東京) / v-okinawa(沖縄) / CSS福笑い(東京) • 好き ◦ 甘いもの(寝起きでケーキもいける) ◦ スプラトゥーン3(トライストリンガー XP1980) ◦ ポケモンSV スカーレット(公式大会に出たい) -
Web制作を振り返り(日本の場合) • 1995年頃・・・ホームページ黎明期、ホームページ・ビルダー • 2000年前後・・・携帯電話、Flash、テーブルレイアウト • 2000年〜・・・Movable Typeリリース(2001)、Blogブーム、WordPress • 2005年〜・・・スマートフォンの登場、レスポンシブウェブデザイン
• 2010年〜・・・モバイルファースト、Googleもモバイルフレンドリーへ • 2015年〜・・・Angular・React・Vue.jsの登場、コンポーネント開発へ • 2018年〜・・・Jamstack、Headless CMS • 現在・・・Next.js・Nuxt、STUDIO、Figma -
2023年現在「Jamstack」という定義の変化 Next.js(React)、Nuxt(Vue.js)のようなフレームワークの登場、 Vercel / NetlifyのようなSSRに対応した環境がそろってきたことで 静的ファイル生成以外の選択肢ができた フロントエンドとバックエンドのコードを分離して、マイクロサービスを組み合 わせて構築していくことそのものをJamstackと呼ぶようになっている (このタイミングで表記も現在のJamstackに) さらに、Jamstackでの開発が当たり前になってきたのでそろそろ死語になるかも
この資料では認識合わせのためにあえてJamstackを使っています -
Jamstackのよくある構成 ヘッドレスCMS データのみを扱う 記事更新してWebhookで連携 エンジニアコードを更新してPushする JSフレームワーク APIでCMSデータを受け取り HTMLと見た目を構築
ホスティングサービス JSフレームワークの 自動Buildに対応 生成したHTMLを配信する -
Webサイト:いわゆるホームページ(コーポレートサイトなど) • 静的ページがほとんど、もしくはCMSで足りる • 状態(state)管理が必要となる場面が少ない • バックエンドは問い合わせフォームくらい Webサービス:事業会社のサービス(SmartHR、Amebaなど)、Webアプリ • ログイン、投稿など、ユーザーからの入力・操作する画面が多い
• 状態管理が必須、動的なページ • バックエンドとの連携が必須 WebサイトとWebサービスの違い(境界線は無い) -
WebサイトとWebサービス(Webアプリ)で二極化 • HTML/CSS/jQuery → 運用はある ------------------------------ • Pug/EJS、Sass(Gulp) • JavaScript(ES6〜)
• MT/WordPress等のCoupled CMS ------------------------------ • Next.js/Nuxt/Astro → Jamstack • Jamstackが基本 • React / Vue • Next.js / Nuxt • コンポーネント開発 • デザインシステム → 素のHTMLで作っていない → TypeScriptが基本 → マイクロサービス化 Webサイト Webサービス/Webアプリ 制作パターンが 多様化 制作パターンが 固定化 -
Jamstackのメリット② コンポーネント開発の恩恵を受けられる • フロントエンドのUI開発の効率化(テンプレートを使い回せる) • ScopedなCSS ◦ コンポーネント内のみに適用されるので他のコンポーネントに影響を与 えない ◦
CSS設計がほぼ不要(BEM、FLOCSSなど気にしなくても良い) • JavaScriptのため独自構文が少ない(MTタグ・WordPress関数) ◦ 他の開発にも応用が効く • フロントエンドメンバーだけでもサービスが作れる -
注意:前提として知っておくべきことが多い • HTML、CSS、JavaScriptの基礎(主に見た目の調整) • CMS設計(DBのデータの持ち方、入力フィールド作成、カテゴリ管理等) • APIのFetch、Promise周りの理解などJS力 + TS力 •
React/Vue.jsのようなライブラリを使ったコンポーネント開発 • Next.js/Nuxt のようなフレームワークのBuild(SSG/SSRなど) • コマンドラインでの操作(Node.jsやGit等) • ホスティング、デプロイ環境の理解(レンサバのみでBuildむずい) • SEO、アクセシビリティをJSフレームワークでどう扱うか -
注意:意外と作るもの多い • ルーティング • ページネーション • 下書きプレビュー • サイトマップXML •
問い合わせフォーム などなど Movable TypeやWordPressならデフォルトで対応していたり、 プラグインでさくっと実装できるものも自分で用意する必要がある -
Movable Type WordPress Headless CMS セキュリティ・低い攻撃リスク 高パフォーマンス(表示速度) 動的処理、リアルタイムに表示を 切り替えられる セキュリティ・低い攻撃リスク
高パフォーマンス(表示速度) クラウド版、パッケージ版、 エンタープライズ版が選べる テーマ、プラグインが充実 JavaScriptに集中できる 公式サポート 開発が早い、実装できる人が多い コンポーネント開発の恩恵 APIがある(Data API) APIがある(REST API) APIがある 要件に合う合わないを考えよう(主観も入ってる) -
Movable Type WordPress Headless CMS MTテンプレートタグの理解が必要 PHP、WordPress関数、テーマの 理解が必要 ReactやVue.js等のJavaScript (TypeScript)、FetchやAPIの理解
コンテンツが増えると再構築に時 間がかかる カスタムブロックをReactで作るレ ベルになると難易度が上がる 基本的に実装の難易度が高い、 作れる人が少ない 詳しい若手が少ない いろいろな構築パターンが生まれ てしまう フレームワークのバージョンアップ による負荷 費用面:初期コスト(パッケージ版) or 運用費(クラウド版) 費用面:アップデートコスト 費用面:ホスティング環境・ビルド 環境が必要で運用費が高め 要件に合う合わないを考えよう(主観も入ってる) -
Jamstack構成 ヘッドレスCMS データのみを扱う 記事更新してWebhookで連携 ※MTのData APIでも可能 エンジニアコードを更新してPushする JSフレームワーク
APIでCMSデータを受け取り HTMLと見た目を構築 ホスティングサービス JSフレームワークの 自動Buildに対応 -
Jamstack構成 ヘッドレスCMS データのみを扱う 記事更新してWebhookで連携 ※MTのData APIでも可能 エンジニアコードを更新してPushする JSフレームワーク
APIでCMSデータを受け取り HTMLと見た目を構築 ホスティングサービス JSフレームワークの 自動Buildに対応 -
Jamstack構成 ヘッドレスCMS データのみを扱う 記事更新してWebhookで連携 ※MTのData APIでも可能 エンジニアコードを更新してPushする JSフレームワーク?
AIエージェント? APIでCMSデータを受け取り HTMLと見た目を構築 ホスティングサービス? チャットUI? SGE? ? -
GitHubのCopilot Workspace(2024年〜) Copilot Workspace で Issue を開くと、意図した変更を実装するためのプランが 自動的に提案されます。Copilot Workspaceは完全に編集可能である〜(中略) Copilot
Workspaceでコードをビルド、実行、テストできます。エラーが発生し た場合は、自動的に修正を提供します。 参照:https://github.blog/jp/2023-11-09-universe-2023-copilot-transforms-github-into-the-ai-powered-developer-platform/ -
開発方法の多様化 • HTMLを直接書く → テンプレートエンジンからGulpでHTML生成 → React/Vue.js等のフレームワークからHTML生成 → ??? •
STUDIOなどのノーコード・ローコード系ツールで生成 • Figma to React、Figma to STUDIO等のデザインからコードに変換し、 デプロイできる仕組みの登場 • ChatGPT等のコード生成、GPTsでアプリ作成 • GitHubのCopilot Workspaceでどうなる? -
課題 • エンジニア育成・教育 ◦ フロントエンドで習得するスキルマップが広すぎる ◦ HTMLとCSSが書けるだけでは作れないものが出てきている ◦ 育成に時間がかかる •
Web環境の転換点 ◦ フレームワークの進化のスピードが早い、開発手法の複雑化 ◦ AIによるプログラミングのブラックボックス化 -
今日のまとめ • 時代の変化に合わせて、サイト制作の作り方も技術も変わっている • Webの専門家でない人が運用できる仕組みを提供するためにCMSは必須 • CMSをどう扱うか、開発手法はメリット・デメリットを考慮して要件に合う ものを選ぶ • Web開発の流行や変化の背景を見つつ、運用に耐えられることを重視しよう
開発するエンジニアも、サイトに訪問するエンドユーザーも、 運用するクライアント様もみんなが使いやすいものを作るために ひたすら考えてます