ライブラリやSDKをメンテナンス/品質保証する際、ある特定バージョンや配布形式、またそれらの任意の組み合わせによってデバッグや動作確認をしたいケースはしばしばあります。 もしそれがnpmパッケージであれば、個別にビルドするのでは手間がかかり、また幾つものバージョンを事前にバンドルするとアプリケーションサイズが膨大になってしまうことが容易に想像できます。
この課題は、Dynamic ImportとViteのビルド設定をうまく組み合わせることで解決することができます。
このトークでは、Viteの具体的なビルド設定の内容を踏まえ、実際にビルドが実行されてからランタイム上でパッケージが解決されるまでのフローも解説しながら、この課題に取り組むにあたり工夫が必要だった点や実装時の注意点を紹介していきます。
ライブラリやSDKをメンテナンス/品質保証する際、ある特定バージョンや配布形式、またそれらの任意の組み合わせによってデバッグや動作確認をしたいケースはしばしばあります。 もしそれがnpmパッケージであれば、個別にビルドするのでは手間がかかり、また幾つものバージョンを事前にバンドルするとアプリケーションサイズが膨大になってしまうことが容易に想像できます。
この課題は、Dynamic ImportとViteのビルド設定をうまく組み合わせることで解決することができます。
このトークでは、Viteの具体的なビルド設定の内容を踏まえ、実際にビルドが実行されてからランタイム上でパッケージが解決されるまでのフローも解説しながら、この課題に取り組むにあたり工夫が必要だった点や実装時の注意点を紹介していきます。
AI補完が頼りないと言っていたのも2年も前。いまやAIは欠かせない存在にまで上り詰めています。
AIは世の中にある情報をもとに学習するので、普及率が高いとは言い難いSvelteは不利かもしれません。
そんな世の中でSvelteを選ぶ理由を紹介します。
・Svelteとは何か
・速い・軽いだけではない、Svelteが優れている点
・AIとの相性
フロントエンドにおける状態管理は、Reactの進化とともに変化してきました。Reduxの登場と普及、Recoilによる宣言的な分離、Zustandのミニマルな設計。そしてReact 18で登場した useSyncExternalStore により、Reactは「状態をどう扱うべきか?」に対して新たな指針を提示し始めています。
本トークでは、これらのライブラリが生まれた背景と技術的課題を時系列で整理しながら、代替わりの必然性と設計思想を考察します。特に useSyncExternalStore に焦点を当て、React標準の視点から状態管理を見直すきっかけを提供します。
長年にわたり、フロントエンド開発の現場を支えてきたSass。
その登場の背景には、当時のCSSが抱えていた課題を解決したいという強いニーズがありました。
それから時が経ち、CSSそのものも大きく進化を遂げています。
Sassが提供してきたような機能も、モダンなCSSで標準的に利用できるものが増えてきました。
このトークでは、モダンCSSの機能を、Sassでおなじみの機能と比較しながら紹介します。
さらに、CSSの進化を俯瞰的に眺めることで、今後のCSSがどのような方向に向かうのかを考察してみます。
想定する参加者
日々のフロントエンド開発において、施策による時限的なUIの変更、新機能のリリース、A/Bテストなどのたびにコード修正・レビュー・デプロイに追われていませんか?
従来のUI開発では、サーバーからデータを受け取るだけでなく、画面構成やUI仕様の変更にもクライアント側の改修・リリースが必要でした。
その結果、開発サイクルが長期化や複数のプラットフォームでサービスを展開している場合、提供同期や仕様ズレ、互換性問題も発生しがちです。
SDUIでは、UI設計情報そのものをサーバー側で管理・制御し、クライアントは設計図に従って安全・迅速にユーザーにUIを提供することができます。
セッションでは、SDUIの技術的構成の例、実際の現場改善ポイント、導入に向けたTipsをコンパクトに解説することで現場で試せるナレッジを共有します。
HTML標準がHTML Living Standardに移行し、Web標準は日々変化し続けています。しかし「この新しいHTML要素、うちのターゲットブラウザで使えるの?」「非推奨になった属性を使っていないか?」といった互換性チェックはフロントエンド開発者には付き物です。
既存のeslint-plugin-htmlやeslint-plugin-compatでは、JSX内のHTML要素・属性の互換性チェックまではカバーしきれていません。
そこで本トークでは、私が開発したESLintプラグイン"eslint-plugin-compat-html"を紹介します。このプラグインはbrowserslist`設定に基づき、JSX内のHTMLタグ・属性のブラウザ互換性を自動チェックします。
マルチプロダクト開発において、ブランドの一貫性を保ちながら迅速にUIを提供する、デザイントークンを活用した開発基盤を解説します。
決済サービス導入事例をもとに、私たちがなぜ一般的なprimitive semanticの2層にcomponentトークンを加えた「3層構造」を導入したのか。その理由と、2層構造の限界、そして3層構造がもたらす柔軟なカスタマイズ性について深掘りします。
技術の核はCSS Variablesです。外部ライブラリに依存しないシンプルな構成ながら、UIライブラリのコードに一切手を加えることなく、利用側がトークンを注入するだけでデザインを自在に変更できる高い柔軟性を両立。私たちの実践から得た、一貫性と開発速度を両立させる設計思想を共有します。
1920×1080の解像度のモニターを使っているお客さんが「レイアウトが見づらい」というので、よくよく話を聞いたら拡大/縮小「150%」で見ているという!
さすがにそんな変な拡大率「150%」になんて合わせて綺麗にしてくださいなんて言わないでほしいと思いますよね?
……それ、ちょっと間違いです!
間違っても「100%で見てもらわないと……」なんて言わないように、ぜひWindowsの「拡大/縮小」と「ディスプレイの解像度」の話を知ってください。
WebSocket通信はリアルタイム性に優れる一方で、接続状態の把握・イベント処理・再接続戦略など、状態管理が煩雑になりがちです。
特にReactアプリケーションに組み込む際は、通信状態をUI上にどう表現するか、状態をどこまで共有するか、といった設計がUXに大きく影響します。
本トークでは、接続・切断・待機・エラーといったWebSocketの状態をReactでどのように扱い、アプリケーション上で視覚的にどう反映するかを紹介します。再利用可能なコネクションの設計、ライフサイクルに応じたイベント管理、スコープに基づいた状態の共有といった観点から、実例を交えて解説します。
Reactでの開発に慣れていた私が、SvelteKitを使ってポートフォリオサイトを構築したところ、高速で開発することができました。本セッションでは、状態管理やコンポーネント設計に悩んでいたReactとの比較を軸に、SvelteKitの驚きの軽快さ、宣言的なUI設計、ファイルベースルーティング、SEO対応など、個人開発で実感したメリットをお伝えします。一方で、SvelteKitの課題や規模による使い分けのポイントにも触れたいと思います。
Webアプリケーションにおけるページ遷移は、コンテンツが切り替わるたびに体験が途切れがちです。そんな中、Chromeで利用可能な「View Transitions API」は、ページ間の遷移にアニメーションを加えることで、よりシームレスで滑らかなUXを実現できます。本セッションでは、ReactやSvelteKit、Next.jsなどモダンフレームワークへの導入や、DOMの変化をCSSアニメーションと連携させる具体的な手法を解説。導入時の制限や落とし穴、どんな場面で効果的かといった実践的な知見をお伝えします。
CSSにも関数的な進化が訪れています。abs()、sign()、sibling-index()、sibling-count()、progress()など、最新のCSS関数を活用することで、これまでJavaScriptで処理していたようなロジックをCSSだけで実現できるようになってきました。本セッションでは、これらの関数の基本的な使い方から、実際にどのようなインタラクションやデザイン制御が可能になるのかをお話します。
「iPhone SEでは大丈夫だったデザインが、iPhone 15 Plusで見ると文字が小さくて読めない…」そんな経験はありませんか?
iPhone SEの375pxからiPhone 15 Plusの430pxまで、わずか55pxの違いですが、約15%の画面幅の差がデザインに大きな影響を与えます。
本セッションでは、「異なる画面幅でも全く同じ内容を表示する」という方針で解決した実装手法を紹介します。pxからremへの移行、画面幅に連動するfont-size設定、CSSカスタムプロパティを活用した効率的な実装方法まで、BtoCサービス開発での実践的な経験をお伝えします。
LLM 時代に急増した「死んだexport」をKnip×ESLintでゼロ化する提案です。
ESLintだけでは検出できない、テストやStorybookで利用されている関数にも対応し、
私の担当するプロダクトでも10以上の関数を削除しています。
プロダクトの信頼性を高めたいフロントエンド開発者
明日の30分で完了できる設定。それ以降は不要な関数とコンポーネントがゼロに。
—
ライブデモ込みの30分です。
私も以前、不安感を持って開発をした経験があり、そんな思いをする方を減らしたいと考えて提案をしています。
私のチームは現在、長年利用されているレガシーシステムの移管プロジェクトに取り組んでいます。
アプリからインフラ、組織体制まであらゆる面で見直しと再設計が必要となり、当然フロントエンドも大規模なマイグレーションが必要となりました。
しかし蓋を開けば遠い昔に見たMarionette.jsやUrushiなど古のフレームワーク群が数多く登場。
フロントエンドエコシステム黎明期に作られたスクリプト群に対し、現代の静的解析はまともに機能しませんでした。
当然ながらAIエージェントも適切に回答できることが少なかったため、自力で解読して再設計することから始めました。
ステップ数は1ファイルあたり3000〜10000強。
それらをモダンな構成へ移行する試行錯誤のなか、巨大フロントエンドをモダンに仕上げる「ツボ」があることに気がつきました。
それらについて、私たちの挑戦と共にご紹介いたします。
振る舞い駆動開発(BDD:Behaviour-Driven Development)は、ソフトウェアの振る舞いを軸に仕様を記述し、それをそのまま自動テストとして活用する開発アプローチです。テストコードが仕様書の役割も果たすため、認識のズレを防ぎやすくなります。
本セッションでは、TypeScriptでBDDを始めるための基本的な考え方と実践方法を紹介します。Cucumber.jsなどのツールを用いることで、自然言語に近い形式で振る舞いを定義し、テストの読みやすさや保守性を高めることが可能です。また、BDDを導入することで、開発者とQAのあいだで仕様の意図や期待される挙動を共有しやすくなるといったメリットにも触れます。
TypeScriptでテストを書いて、これからBDDを始めたい方に向けてわかりやすく解説します。
振る舞い駆動開発(BDD:Behaviour-Driven Development)は、ソフトウェアの振る舞いを軸に仕様を記述し、それをそのまま自動テストとして活用する開発アプローチです。テストコードが仕様書の役割も果たすため、認識のズレを防ぎやすくなります。
本セッションでは、TypeScriptでBDDを始めるための基本的な考え方と実践方法を紹介します。Cucumber.jsなどのツールを用いることで、自然言語に近い形式で振る舞いを定義し、テストの読みやすさや保守性を高めることが可能です。また、BDDを導入することで、開発者とQAのあいだで仕様の意図や期待される挙動を共有しやすくなるといったメリットにも触れます。
TypeScriptでテストを書いて、これからBDDを始めたい方に向けてわかりやすく解説します。
LINEのミニアプリやLIFFを活用すると、スマートフォン向けのアプリを手早く構築できます。
この仕組みをつかった、イベントむけ謎解きゲームアプリのご紹介です。
Vite+React のSPAに@line/liff SDKを組み込んでいます。
エンジニアアサインを、「1人1案件の専任制」から「全員で全案件担当」の体制にしたら
成長を楽しむタイニーチームに育ちました。
コミュニケーションし、同じことに取り組む。
そのシンプルな積み重ねが
プロンプトを構造化するように、思考をI/Oする力を鍛えます。
1年半つづけてみたリアルな手応えを語ります。
ひとりで何でも作れてしまう時代に、チームで戦って成長する楽しさ。ぜひ聞いていただきたいです。