フロントエンドカンファレンス関西 2025 #fec_kansai なぜフロントエンド技術を追うのか？
 なぜカンファレンスに参加するのか？ @__sakito__ 

自己紹介 sakito(@__sakito__) サイボウズ株式会社 プロダクトデザイン部 マネージャー プロダクトエンジニア(フロントエンド) マネージャー みんなのデザイン室リーダー フロントエンド技術を追ったり、話すのが好き mozaic.fmのMonthly Ecosystem会に月1でゲスト出演 

なぜカンファレンスに来たのでしょうか？ 

今日話したいこと 貴重な休日に、チケットを購入して、カンファレンスに来た意味を堪能してほしい 私なりの、フロントエンドの技術を追うこと、カンファレンスに参加することの意図を伝えます 

なぜフロントエンド技術を追うのか？ 

フロントエンドの変化は速すぎて、追うのは疲れる？ 新しいWeb APi Webpack Rstack Vite Oxc ESLint Biome CSSの追加 ES 20XX TSの新しいバージョン React Next.js Vue Angular Remix Nuxt.js HTMLの追加 Svelte なにを追いかければいいんだろう... 

流行を追うのではなく、「流れ」を楽しむ 流行を追うだけなのは確かに疲れる 使うかも分からないものを学ぶ気になれない フロントエンドの「流れ」を楽しむ 新しい技術やライブラリの誕生がどんな課題を解決し、次に繋がるのだろう？ 技術を点ではなく線で捉える 

「流れ」ってなんだろう？？ 

ビルドツールを例に流れを知る 

ビルドツールを例に流れを知る Q. Viteをみなさん知っていますか？ 

ビルドツールを例に流れを知る Q. Viteはなぜ誕生したのでしょうか？ 

ビルドツールを例に流れを知る Q. Viteはなぜ誕生したのでしょうか？ Vueのため？Reactでも使えますよね？ ただ「速い」ことがViteが生まれた理由？ 

ビルドツールを例に流れを知る 誕生の理由を過去の課題から見る How
 使い方がわかる Why
 なぜ必要になったか? 

ビルドツールの流れ 2010年頃 2010年頃 2012~20年頃 2021年頃 ~2025年 モジュールの概念なし
 バンドラーなし Browserify Grunt,Gulp webpack Rollup Parcel Vite Rspack Turbopack Bun build 

webpackとVite webpackはフロントエンド開発の大きな基礎を築き上げた すべて(CSSやアセットなど)を1つのJSファイルにまとめるバンドル ReactのJXSやTSのトランスパイルも組み込んだ Code SplittingやHot Module Replacement(HMR)も組み込んだ フロントエンド開発の大きな基礎を築き上げた webpackが大規模なアプリケーションで使われるようになったことで新たな課題が生まれた 複雑になる設定ファイル HMRやビルド速度の低下 Viteがwebpackの課題を解決するために作られた Goの普及によりesbuildなどのツールが生まれ、ブラウザにネイティブESMやimport mapが入った Rollupとesbuildを組み合わせビルド速度の改善や設定ファイルの複雑性の課題を解決した webpackが作った流れの中で課題となった部分をViteが産み出した webpackがダメなのではなく、Viteがwebpackから新しい流れを生み出した Rustが普及し、高速化の時代へ... ViteのRolldown移行,Rspack,Turbopack 

詳しくはVite: The Documentaryでも語られている Vite: The Documentary - YouTube
 https://www.youtube.com/watch?v=bmWQqAKLgT4 

ビルドツールの流れ 2010年頃 2010年頃 2012~20年頃 2021年頃 ~2025年 モジュールの概念なし
 バンドラーなし Browserify Grunt,Gulp webpck Rollup Parcel Vite Rspack Turbopack Bun build 1つ1つの技術は繋がって新しいエコシステムを生み出している 

エコシステムからWeb標準へ 

エコシステムからWeb標準へ JS0/JSSugarという構想がTC39に提案された(2024年) Language Evolution - Google スライド
 https://docs.google.com/presentation/d/1ylROTu3N6MyHzNzWJXQAc7Bo1O0FHO3lNKfQMfPOA4o/edit?slide=id.g30432c5cd9c_0_693#slide=id.g30432c5cd9c_0_693 

エコシステムからWeb標準へ ビルドツール前提であるエコシステムから言語実装としてWebブラウザに入る流れになっている しかし、ラインタイムエンジンは複雑になり、セキュリティのIssueも増えてきた そこで、ラインタイムエンジンと、エコシステムの役割を分けて、シンプルに保てる仕組みの提案が出た JS0: エンジンによって実装される言語 JSSugar: ツールによってJS0にコンパイルされる必要がある機能 開発者にとっては、JS = JS0 + JSSugar 

Web標準の議論でも
 エコシステムの流れがあった 

TPACに参加してきた TPAC = Technical Plenary and Advisory Committee W3C が開催する全体会合 サイボウズは今年W3Cの会員になりました！ 一週間の開催で、様々なWorking GroupやCommunity GroupによるMTGが開催される Accessibility Guidelines WG,Web Applications WG,Web Components CG,whatwg,etc... 

TPACであった議論の一部 DOM Templates JavaScriptで宣言的なHTMLテンプレートを記述し、DOMを効率的にレンダリング・更新するためのAPI 当たり前に使っているJSX(ビルド無しで動かない)からブラウザが持っていないHTMLのテンプレートへ DOM Parts テンプレートの属性、プロパティ、イベント、子などのバインディング箇所におけるDOMの最小限の更新 を可能にする構成要素 Reactの差分更新に近い DOM Scheduling DOM更新の順序付けをおこなうAPI

 これらの機能はすでに開発者が使っているもエコシステムから大きな影響を受けている 1つ1つの機能について、現場の開発者がどのようなニーズをもっているか議論がなされた webの後方互換性、開発しやすいAPIはどのようなものか？、どのような場面で必要とされるか 最終的に3つ一気に進めるのではなく、1つの機能から進めていくのはどうだろうという議論になった 

TPACで感じたエコシステムとWeb標準の大きな流れ Webにまつわる仕様を考えている人たちは、開発者の声をとても求めている 使いやすいAPIになっているだろうか？ バグはないだろうか？ 今本当にブラウザに必要なものはなんだろうか？ 多くの開発者にとってよりよい仕様を作るために1つ1つの議論を進めている Webブラウザとエコシステムを掛け合わせて開発しているのは、仕様を考えている人ではなく、世の中に多く いる私たちのようなアプリケーション開発者たち エコシステムの声を届けることが仕様への貢献となる jQuery $(...)→querySelector Moment.js →Temporal API SassのNesting→CSS Nesting Signals(フレームワーク)→Signals (TC39 Proposal) エコシステム Web標準 エコシステムが活用 大きな流れ 繰り返していく 

なぜフロントエンド技術を追うのか？
 それは過去と今の流れから課題を把握し、課題にあった技術を 選んでいくため 

なぜカンファレンスに参加するのか？ 

フロントエンド技術を実際に使った
 知見と現場の話を知れるのが
 カンファレンスや勉強会 

勉強会やカンファレンスで知れること Docs/記事 Getting Startedではじめ方 DocsでAPIの解説 記事で触れられる使い方 記事は抽象化されてる上に話を聞けない 勉強会/カンファレンス 技術を現場で使った生の体験 疑問に感じたことを直接聞ける 廊下や懇親会で聞ける多くの経験談とノウハウ 

勉強会やカンファレンスで知れること Docs/記事 Getting Startedではじめ方 DocsでAPIの解説 記事で触れられる使い方 記事は抽象化されてる上に話を聞けない 勉強会/カンファレンス 技術を現場で使った生の体験 疑問に感じたことを直接聞ける 廊下や懇親会で聞ける多くの経験談とノウハウ カンファレンスは
 技術を追うだけでは得れないノウハウを知るチャンス！！ 

カンファレンスは共通の話題がある 会場全員が「共通の話題」を持っている 聞いた登壇内容について登壇者に聞くだけではなく、周りと話すことができる スポンサーブースで気になる企業の取り組みついて聞ける 

カンファレンスは共通の話題がある 「共通の話題」がある便利さ 普段、技術の話をするとき、相手のバックグラウンドを探り、前提を共有し、文脈を説明する必要がある カンファレンスでは、その「文脈共有コスト」がゼロになる 同じセッションを聴いた人たちは、全員が同じ話題を持てる そもそも会場にいる人がフロントエンドについて取り組んだり、興味ある人たち 

なぜカンファレンスに参加するのか？
 カンファレンスとは、技術を現場に落とし込む「問い」について語る場。 ドキュメントには「どう使うか」は書いてあるが、「どう現場に落とし込むか」 は書いていない 

なぜカンファレンスに参加するのか 問いの例 「この技術、うちの現場で使える？」 「どうやって導入する？」 「どんな課題がある？」 こうした「問い」を、実際に現場で使っている人たちと語り合える場 

カンファレンスの場をぜひ活用してみてください！ 登壇者に話を聞きにいく あの話、うちの会社だと〇〇なんですが... 登壇内容は「キレイなこと」が多い、現実は「もっと泥くさい」ことだらけ スポンサーブースに話を聞きにいく 過去に見た記事や資料について聞くチャンス！ 聞いた登壇内容について周りの人と話してみる さっきの〇〇、使ってます？ 廊下や休憩スペースでざつだんをふっかけてみる どんな登壇聞きましたか？ 懇親会で近くの人に何の登壇を聞いたか話してみる ハッシュタグを使ってSNSにポストして疑問を聞いてみる、感想を書くだけでも登壇者はうれしい！！！ これも立派な参加 登壇を聞くだけは、オンラインでもできる。
 現場の知見を得て、明日から活用できるチャンス！！！！ 

なぜカンファレンスに参加するのか？
 カンファレンスとは、技術を現場に落とし込む「問い」について語る場。 ドキュメントには「どう使うか」は書いてあるが、「どう現場に落とし込むか」 は書いていない 他社の「生きた知見」を持ち帰り、自社の技術選定に活かす ドキュメントには書いていない「実際の使い方」を知れる 成功事例だけでなく、失敗談や課題も聞ける 

最後に... コロナ禍で1度途絶えた、小さな勉強会のコミュニティ 今回のカンファレンスが初コミュニティイベントなの人もいるのでは？ 年1のカンファレンスで終わりではなく、小さなコミュニティの勉強会も盛り上がって、現場の知見を交換し 合えることにも価値があると個人的におもう 地方カンファレンスでの繋がりが小さな勉強会が生まれる,参加するきっかけになるんじゃないだろうか？ 自分自身も小さな勉強会に助けられてきた あたたかく登壇の機会を与えてくれた LTでも登壇できるハードルの低さ 頻繁に現場の知見を教えてくれる人たちのおかげで自分のスキルアップにもなった 小さな勉強会をきっかけにカンファレンスに呼んでくれた、スタッフにしてくれた 転職のキッカケにもなった こういったカンファレンスが成り立ち、良い体験になるのはいろんな要因がある 運営の方、スポンサー、登壇者だけではなく、参加者が居ないと成り立たない
 カンファレンスが終わったらそこで終わりではなく、次のコミュニティに繋がると、また来年のカンファレン スも楽しそうだなとおもう いっぱい知見が聞ける機会が増えると楽しい！！！ 

なぜフロントエンド技術を追うのか？ なぜカンファレンスに参加するのか？ 

なぜフロントエンド技術を追うのか？ Enjoy the Frontend!! なぜカンファレンスに参加するのか？ Enjoy the Conference!! フロントエンドもカンファレンスもとにかく楽しむのが1番！！！