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分です。
私も以前、不安感を持って開発をした経験があり、そんな思いをする方を減らしたいと考えて提案をしています。
普段の開発を行っていると、mdnのCSSリファレンスを端から読むことってそんなに多くはないと思います。
ですが改めて読んでみると、「知らなかったけどこれは便利だな!」というものから「このプロパティいつ使うん?」とつい思ってしまう様なマイナーなものまで、様々なプロパティと出会うことができます。
今回の発表では、mdnのCSSリファレンスを全て読んで見つけたマイナーなプロパティを紹介しながら、何とか業務内でも用いることが出来そうな用途を可能な限り捻り出して紹介します。
「自分でmdnを通読するのはめんどくさいけど、何か面白いものがあるなら知りたい!」という贅沢な方々に向けて、すぐに業務に役立つ訳ではないけれど知っておくといつかどこかで使えるかもしれない知識をお届けします。
私のチームは現在、長年利用されているレガシーシステムの移管プロジェクトに取り組んでいます。
アプリからインフラ、組織体制まであらゆる面で見直しと再設計が必要となり、当然フロントエンドも大規模なマイグレーションが必要となりました。
しかし蓋を開けば遠い昔に見たMarionette.jsやUrushiなど古のフレームワーク群が数多く登場。
フロントエンドエコシステム黎明期に作られたスクリプト群に対し、現代の静的解析はまともに機能しませんでした。
当然ながらAIエージェントも適切に回答できることが少なかったため、自力で解読して再設計することから始めました。
ステップ数は1ファイルあたり3000〜10000強。
それらをモダンな構成へ移行する試行錯誤のなか、巨大フロントエンドをモダンに仕上げる「ツボ」があることに気がつきました。
それらについて、私たちの挑戦と共にご紹介いたします。
「overflow: auto を指定したのに横スクロールできない」「長いコンテンツが親要素を突き抜けてしまう」そんな経験はありませんか?
私自身、横スクロールが効かない問題に直面した際、原因は親要素に設定された flex-direction: row でした。
実は、こうした構造的なレイアウト崩れは、FlexboxではなくGridを使うことでスマートに解決できるケースが少なくありません。
本LTでは、実際に遭遇した問題を通じてFlexboxの仕組みを解説しつつ、Gridレイアウトがより適切な選択肢となる理由をお伝えします。
min-width: auto の罠、不要なdivの増加、非セマンティックなHTML構造といった問題が、Gridでどのようにスマートに解決されるかを実例を交えて紹介します。
「とりあえずFlex」から一歩進み、意図に応じたレイアウト手法を選べる開発者を目指しましょう。
「あ、このアニメーション気持ちいい!」 - そんな体験には再現性があります。
本セッションでは
をデモ中心で解説します。
フロントエンド初級者でも「セッション後すぐに試せる」具体的 Tips を持ち帰れる内容です。
モノリス化が進んだプロダクトの中で、「ユーザー影響の少ない画面から段階的にフロントエンドを切り出していこう」
そんな構想から始まった、バックエンド・フロントエンドの分離プロジェクト。
Next.js を使い、OpenAPIで型生成を行い、アーキテクチャパターンを学び…将来的にプロダクト全体への展開も視野に入れていましたが、
結果的に今は「撤退」を選ぶことになりました。
本セッションでは、どんな構想を立て、なぜ実行に移し、そしてどこで限界を感じたのかをリアルに共有します。
同じようにフロントの切り出しを検討しているチームにとって、立ち止まって考えるきっかけになれば幸いです。
振る舞い駆動開発(BDD:Behaviour-Driven Development)は、ソフトウェアの振る舞いを軸に仕様を記述し、それをそのまま自動テストとして活用する開発アプローチです。テストコードが仕様書の役割も果たすため、認識のズレを防ぎやすくなります。
本セッションでは、TypeScriptでBDDを始めるための基本的な考え方と実践方法を紹介します。Cucumber.jsなどのツールを用いることで、自然言語に近い形式で振る舞いを定義し、テストの読みやすさや保守性を高めることが可能です。また、BDDを導入することで、開発者とQAのあいだで仕様の意図や期待される挙動を共有しやすくなるといったメリットにも触れます。
TypeScriptでテストを書いて、これからBDDを始めたい方に向けてわかりやすく解説します。
package by featureは、機能や関心ごとにディレクトリを切るディレクトリ構成です。
/hooksや/contextsといった技術ごとにディレクトリを切るpackage by layerはひとつの機能が分散して配置されるのに対して、package by featureはひとつの機能が一箇所にまとまっているのが特徴です。
しかし、実際にどのようにfeatureを切っていくのかについて取り上げている情報は、まだ少ないように感じます。
一方で、コンポーネントのDomain(関心)に特化した分類には、コンポーネントを関心・状況・基礎の3つの軸で分類することで体系的に管理できるBCD Designという手法があります。
そこで、本セッションではBCD DesignにおけるDomainの概念を応用し、featureをどのように切り出していくのかについて具体例を交えて紹介します。
振る舞い駆動開発(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年半つづけてみたリアルな手応えを語ります。
ひとりで何でも作れてしまう時代に、チームで戦って成長する楽しさ。ぜひ聞いていただきたいです。
HTML属性のcontenteditableは要素内のテキストを編集可能にします。主にリッチテキストエディターの実装で使われますが、テキストが編集可能になるという点以外は通常の要素と変わらないため、文字装飾だけではないさまざまなUI表現の可能性があります。
その例として、画像を自由な場所にドラッグアンドドロップで配置できるスクラップ帳エディターを実装しました。その実装をもとに、エディターの挙動に影響させずにVueを使う方法などの役立つ話や、ブラウザーごとの挙動の違いや日本語入力時のつらみなどの泥臭い話をします。
contenteditableを使ってちょっとおもしろいUIを作ってみたい方にはもちろん、アプリ開発の泥臭い話が好きな方にも楽しんでいただけるセッションになると思います。
AI活用により開発速度が劇的に向上する現代。GitHub CopilotやCursor等のAIツールで、コード生成は驚くほど高速化しました。しかし、速度重視で品質管理を疎かにすると、技術的負債は加速度的に蓄積し、いずれプロジェクトは破綻します。
本セッションでは、「ESLintが十分に活用されていなかった」プロダクトを、段階的に改善してきた実践事例を共有します。
AI時代の開発において、適切なガードレールを設置することは、持続可能な開発の必須条件です。本セッションが、技術的負債と向き合う勇気と具体的な方法を提供できれば幸いです。
フロントエンド開発では様々なライブラリやツールがあります。
例えば、UIフレームワーク、メタフレームワーク、ランタイム、CSS、UIフレームワーク、パッケージマネージャ、モバイル&デスクトップアプリ、ビルド・バンドルツール、モノレポツール、バックエンドフレームワーク、テストツール、リンター・フォーマッターツール、型ツール…
そんな数多のエコシステム周辺の今年のアップデートを振り返り、どのようなもの生まれてきたか・変わってきたかを振り返ってみようと思います。
その中から来年以降はどのような変化があるのかを考察してみます。
フロントエンドカンファレンス関西の開催日時点で2025年も残すところ1ヶ月です。
このセッションを聴きながら皆で振り返ってみませんか?
皆さんはフロントエンドテストを書いていますか?
バックエンドテストがあるのに、フロントエンドは手つかず。そんな現場は珍しくありません。
私たちのプロダクトも、テストがあったものの重要な部分はカバーされていない状態からスタートしました。
「何を、どこまでテストすべきか」 が曖昧なままでは、導入は前進しません。
そこで私たちはクリティカルユーザージャーニーに絞った「必要十分」なテスト戦略を策定し、
限られた工数で最小の投資から最大の品質向上を実現し、壊れにくいテスト基盤を構築しました。
本セッションでは、
これらを具体的なコード例とともに紹介し、堅牢なフロントエンドテスト基盤を構築する方法を共有します。
国内外であまり知られていないAstroのContainer API。主にコンポーネントテストのために使われますが、実はバックエンドフレームワークとの組み合わせも可能にするAPIです。
本発表では、Astro Container APIの紹介、バックエンドフレームワーク組み込みのための使い方、APIを使うときの落とし穴について語りたいと思います。HonoやLaravelなどを利用し、実例を紹介しながら発表します。
「Astroを使ってるけどバックエンドを追加したい!」 「既存のバックエンド知識を活かしながらモダンなUI開発をしたい!」 という方に向けたトークです。
フロントエンドをTypeScript(以下TS)以外の言語で記述したことはありますか?多くの方は非TSと聞くと、テンプレートエンジンを思い浮かべるかもしれません。
本セッションでは、Python製のライブラリ「Streamlit」に焦点を当て、非TS言語における動的なUIライブラリの実装手法と構造を紐解きます。TS以外の言語でモダンなフロントエンドを書いてみたい方が対象です。
StreamlitはPythonコードのみで動的なUIを提供できるという特徴があります。さらに、実行形式が.py
なので、LLMライブラリとの親和性が高いです。この特性によってStreamlitはLLMアプリのPoC用途で存在感を高めています。しかし、その通信方式や描画ロジックを深く理解している方は少ないのではないでしょうか。
本セッションを通じて、聴講者は動的なUIを自由な言語で作れるようになるでしょう。
フロントエンドステート管理の大きな潮流に細粒度リアクティブステート管理 (fine-grained reactivitiy) が挙げられます。Solid.js や Svelte, Angular, Vue, Preact など様々なフレームワークで採用されている考え方で、Signals として TC39 で標準化の議論もはじまっています。
本セッションでは、React を題材にフロントエンドステート管理の歴史を紐解きながら、各時代が解決した課題と限界を振り返りつつ、なぜ細粒度リアクティブという考え方が必要になったのか、また、新しく見えてきたスコープ管理という設計課題を考えていきたいと思います。
その上で、Jotai / Bunshi を導入した実プロダクトでの事例をもとに、細粒度リアクティブステート管理における実践的なスコープ設計の解決策を紹介します。