トーク

「Webフロントエンドは混沌としている」と話題となることが増えてきましたが,果たしてそれは事実なのでしょうか？それは「フロントエンドエンジニア」という役割の存在を否定するものなのでしょうか？
私自身が個人でWebの歴史についてまとめたScrapboxを元に、個人的見解を織り交ぜフロントエンドの魅力とそこに携わるエンジニアの役割について発表します.

＜話すこと＞
・WorldWideWeb登場から現代までのWebフロントエンド発展の流れ
・フロントエンドがなぜ魅力的なのかについて
・フロントエンドエンジニアだからこそできる企業,社会への技術貢献

<話さないこと＞
・具体的な技術スタックやフレームワークについての話

＜聴きに来て欲しい人＞
・自分の役割に迷っているフロントエンドエンジニア
・昨今のフロントエンドに違和感を覚えている方

本テーマでは、ダークテーマの実装時に、UI上で魅力的なカラートークンとアクセシビリティの基準を満たすカラートークンの設計方法について深く掘り下げます。
具体的には、Qiitaの実例をもとに、適切なカラーパレットの選定基準や方法、コントラスト比の最適化、効果的なカラートークンの設計方法に焦点を当て話します。
特に、Qiitaのカラートークンは「ブランドカラーとUIカラーを分ける戦略」と「拡張性を持たせた設計」を特徴としています。これは、「エンジニアを最高に幸せにする」というQiitaのビジョンと「デザインシステムは進化し続けるものである」という思想に基づいて設計しました。
このアプローチを他社でも応用・利用できるように話す予定です。

本発表では、フロントエンド開発におけるブラウザ互換を意識することの重要性に焦点を当てます。

過去の歴史的なブラウザ戦争から現代に至るまでを振り返りつつ、開発者やユーザーが直面するブラウザの課題と互換性の重要性を語ります。

• IEサポートという歴史を振り返りつつどのようにして現在の主要なブラウザたちが残ったのかを詳しく見ていきます
• Web標準に準拠した互換性がなぜ重要であるか、それが損なわれたWebはどのように影響を与えるかを掘り下げていきます
• ブラウザ互換性を維持するための各種取り組みを紹介し、エコシステム全体の健全性に貢献する方法を模索していきます

ブラウザ互換を意識したフロントエンド開発は、単なる開発者だけの問題を超えるWebの未来を守るための責務です。
このセッションで、ブラウザ互換の理解を深め、日々の開発において適切な意思決定ができるようになることを目指します。

古くはSASS等のプリプロセッサ系言語から、CSSモジュール、CSS in JS、ゼロランタイムへの希求など、CSSを扱う手法は注目を集めてきました。
昨今ではlayerやnestingの導入に代表されるように、CSS自体の機能も充実しつつあります。

ところで、CSSでのレイアウトを実装するとき、どれくらい仕様にある概念を意識しているでしょうか？
基本のボックスモデルはいいですよね。マージンの相殺、重ね合わせ順といった頻出問題ではどうですか。レイアウトは何の指定によって動作を変えるのでしょうか。
なんとなくうろ覚えのプロパティを書いて、ホットリロードの結果を見ながら試行錯誤する時間とはおさらばしましょう。

論理的にCSSでのレイアウトを構築する力をつけるための知識、困ったときに検索できる知識をつけて、道具選びではごまかせないモダン以前のCSS力を確かなものにするためのトークです。

エッジコンピューティングが急速に普及する中で、フロントエンドとバックエンドの従来の境界がどのように変化しているのか、そしてエッジをどちらのカテゴリに分類するかは面白いトピックです。
このセッションでは、エッジがフロントエンドとバックエンドのいずれに属するのか、またはそもそもこのような区分けが適切かどうかを探ります。技術的な境界がどのように変化しているかを見つめ直し、エッジが伝統的なカテゴリにどのように収まるのかを検討します。

本発表ではレガシーなフロントエンド開発の経験しかないチームが、デザインシステムとコンポーネント指向を導入し、従来の開発プロセスをどのように革新したかを、実例を交えて紹介します

このチームはレガシーなコードの肥大化と複雑化に伴い、メンテナンス性と拡張性の問題に直面していました
新たなサービス開発を機にアトミックデザインをベースにしたデザインシステムの導入と、SPAフレームワークを用いたコンポーネント指向開発に挑戦しました

コンポーネント指向はUI の再利用性と組み合わせ性が向上させ、サービスを高品質に、なおかつ柔軟性をもたらしました
さらにデザインシステムの導入はチーム内のコミュニケーションと協業にも好影響を与えました
共通言語はデザイナーと開発者の連携がスムーズに変化させました

本発表を通して、コンポーネント指向に立ち向かう具体的なイメージを持っていただけると幸いです

長くウェブサービスを運用していると、どうしても jQuery と付き合わなければいけない瞬間があります。
10年間の運用で40万行規模にふくらんだコードベースを管理しながら、より安全で、メンテしやすく、そして将来的に宣言的 UI に移行できるようにするために、
どのように開発計画を立て、リファクタリングを進めていったのかをお話しします。

• チームとコードベースが抱えていた課題
• 不要コードの削除
• セキュリティ問題の解消
• ESLint・スペルチェッカの導入
• 型チェックの導入
• バンドラーの導入

皆さんは、ユーザーの手元で起きたバグをなかなか再現できずエスパーで直した経験はないでしょうか。あるいは、ユーザーの動きを想像しながら機能の導線改善をした経験はないでしょうか。
そんな仕事を楽にするツールとしてSentryやDatadog、Fullstoryなどが、ユーザーの画面をそのまま見れるセッションリプレイ機能を提供しています。

さて、これはどのように実現されているのでしょうか。Webアプリの画面をmp4動画として録画することはもちろんできません。代わりにMutationObserverをはじめとしたWeb標準技術を駆使して擬似的な録画を実現しています。

本セッションでは、自作のセッションリプレイツールを3年間運用している経験を元に、それを支えるWeb技術と具体的な実装を解説します。実運用するためのプライバシー対応やサーバー側実装についても紹介します。

コードベースに秩序をもたらすため各種 Linter を利用している方も多いのではないでしょうか？一般的なルールについては Linter 内蔵のものや既存の Plugin ですでにカバーできるでしょうが, 一方で事業ドメイン特化であったり UX/DX を向上させるための技術ドメイン特化なルールまではサポートし切れないケースの方が多いでしょう.

日経電子版においてもコードベースにそうした事業ドメイン, 技術ドメイン特化な制約が存在しています. こうした日経電子版特化な制約について日経電子版開発では属人的なレビューで弾くといったアプローチでなく, できるものは ESLint Plugin を開発してそれにより機械的に弾くアプローチをとっています.

本セッションでは事業, 技術ドメイン特化な ESLint Plugin を開発する利点や How To を具体例とともにご紹介します.

ウェブ開発においてJS/TSを利用することが多い中でWasmを組み込もうとするとJS/TS以外の言語(RustやC++など)を利用するのが最初の選択肢になるのではないでしょうか?

JS/TS以外の言語がWasmへのコンパイルをサポートすることでウェブへ進出できるようになるのは喜ばしいものの，JS/TSを中心としたウェブ開発の中で他の言語を導入するコストをどう見るのか?

本セッションではJS/TSと比較した時のWasmのメリットデメリットを踏まえつつ，ウェブ開発の中でWasmを導入する時の最初の選択肢として「AssemblyScript（AS)」を紹介します．
ASはnpmで管理されているためにウェブ開発において手軽に導入でき，かつ書き慣れているTSをWasmにコンパイルできる技術です．
ASを用いたWasmの導入方法や現状できることを中心に話したいと思います．

昨今、街歩きがブームとなり、歴史的な地図への関心が高まっています。
「れきちず」は昔の歴史地図を現代風のデザインにアレンジし、誰もが使いやすく読みやすい地図へと進化させました。
「れきちず」は見た目だけでなく技術面、フレームワーク・地図タイル・3D地形・データ変換のパイプライン…などなどがフロントエンド技術を中心としたユニークな技術スタックで構築されています。
このセッションでは「れきちず」のオモテ側のデザインを紹介しつつ、ウラ側の技術についても深堀します。

概要:
アプリケーションの構築にComponent-Drivenなアプローチがあります。このアプローチでは、コンポーネントを中心とした設計がデザインと開発の両面で重要です。しかし、デザインとフロントエンド開発の間にはしばしばコミュニケーションの断絶が見られ、結果としてコンポーネント設計において不一致が発生します。
このセッションを通じて、デザイナーとフロントエンド開発者がより効率的に協力し、一貫性のあるユーザー体験を創出できるようになることを目指します。

内容:
・ Figmaの進化： DevMode、Code Connect、フロントエンド開発者も知っておきたい内容を抜粋
・ Storybookの利用: テスト、ドキュメント、FIgmaとの連携など、Storybookの利用方法を実際の取り組みを交えつつ紹介
・ HTML,CSSの変化： コンポーネントにフォーカスした技術の変化を紹介

JavaScriptとwasmを連携させる場合に問題となるのが、非同期処理の扱いです。
特に、現在のwasmは同期的に実行されるものであり、JSと連携させた場合には同じコールスタックを共有します。
そのため、wasmからJSに制御を移し、非同期処理を行ってからwasmに制御を返すといった挙動を実装するためには工夫が必要になります。

このトークでは、Rustでwasmを出力する場合について、非同期処理を行うJS側とwasm側を連携させる方法をいくつか解説します。
特に、wasm-bindgenは使わずにボイラープレートを最小化し、Rust本体の機能と自前の実装で済ませてしまうのが見どころです。

キーワード: 非同期処理、非同期ランタイム、イベントループ、JSPI (JavaScript-Promise Integration)

複数言語をサポートするwebアプリケーション開発において文言の国際化は常に付きまとう問題です。特に日付や数値の表記、文法規則などを考慮した国際化はその処理や管理で悩むことが多いと思います。

webフロントエンドにおいては、このような機能をJSの国際化APIであるIntlが担うようになってきています。一方、日付や数値など個別の国際化機能が充実していく中で、文言全体のフォーマットをどう定義しどう書式化するかと言う課題に対しては未だ答えが出ていません。

このような課題に対し、仕様レベルで文言のフォーマットやパース・書式化をサポートする「Intl.MessageFormat」という野心的な提案が現在Unicodeを巻き込んで協議されています。本セッションではこの提案について、その背景や概要、現在までの流れ、提案されているフォーマットを紹介し、標準化された後の文言国際化を考えたいと思います。

ブラウザによる「テキスト描画」について、Chromiumへのコントリビュートを通じて得た知見をもとに深ぼります。

ブラウザが受け取ったデータはシェイピングエンジンやグラフィックライブラリなど、様々なモジュールを通って初めてモニター上のピクセルとして具現化されます。

ただし、多くの要素が事態を複雑にします。

フォントの変更。CSSによる線や強調点、カゲの付与。
カーソルにより選択された部分のハイライト。

縦書きもあります。アルファベットは時計回りにまわしましょうか。

……アルファベットとひらがなが混ざった縦書きもあるのか。

えっ、隣に来る文字に依って形が変わる文字がある？

そういえばカゲって、強調点のカゲも描画しないといけないんでしたっけ？

えっ、打ち消し線のカゲがテキスト本体より前に来てしまうバグ？

……さて、ブラウザはどのようにしてテキストを描画しているのでしょうか。

普段の開発でCSSを書く機会は多いかと思いますが、
その際にCSSが適用される優先順位はどのぐらい把握していますか？

詳細度・ !important・style attribute などは利用頻度が高いため広く理解されていますが、
昨今では Cascade Layer・Shadow DOM・Scoping Styles といった新しい概念が利用可能となり、
従来の知識では説明できない範囲が追加されており、
CSSの適用順序の学び直しが必要な時期が来ています。

このセッションでは、CSSの適用順序 = Cascade Sorting Order について、
新仕様も踏まえ整理すると共に、いままで何気なく利用していたものについても
深堀りした内容についてお話します。