BuriKaigi 2026 の参加したので、個人的メモを残しておく。
2025年のWebフロントエンドの振り返りと2026年
スライド:
https://www.docswell.com/s/sakito/ZEY2P7-burikaigi2026
Baseline：ブラウザ互換性の共通指標
VSCodeでCSSのプロパティホバーでBaselineのサジェストが出るようになった。
フロントエンドツールにBaselineが組み込まれている。
Chrome売却問題とスマホ新法
Chromeは独禁法をめぐって裁判中。
ブラウザエンジンのwebkit固定にする縛りがなくなったが、先行するEUでは、それでもWebkitのみになっている現状がある。
AIとブラウザの関係
こういったブラウザが使われることで、Web技術への要望や人々のセキュリティに対する意識が変わるかもしれない。
デザインツールの進化：Figma Make
Figma Make。 Makeでデザインファイルに変換して、Makeで作成したものを編集など。
Makeでnpmを読み込ませる機能も、限定でリリースされている。今後社内のパッケージなどを活かせるようになるかも
エディタとデザインの融合
エディタ上でデザインできるツールの発達。
Fusion気になる。
Void Zeroとフロントエンドツールチェーン
Oxlint, Oxfmtが出てきた。
ESlintやprettierの互換性に取り組みを進めている。
Next.js以外のフレームワーク動向
Next.jsのReactの境界線がわかりづらくなっている。
標準化されていないものが多く含まれている。
デジタル民主主義、政治抜きで。
url:https://fortee.jp/burikaigi-2026/proposal/3d5b72c7-a96a-49f3-a434-c7f169def5db
Polimoneyとは
スウェーデンで運用されている透明性の高い政治システムを参考に発足。
政治資金収支報告書の課題
PCで作られているが紙で保管。
二重線訂正印で手書き訂正などもあり、DX化がむずかしい。
都道府県ごとのフォーマット + 総務省のフォーマットで
48種類のフォーマットが存在。
💬 就労証明書でも同じのようなことがあったな。
選挙費用報告書のフォーマット問題
選挙に立候補した人一人一人が提出するもの。
富山県と富山県南砺市ではフォーマットが違う。
市区町村での違いがありそう。
Polimoneyでの可視化手法
サンキー図を使って、政治資金収支報告書を見える化。
選挙費用報告書は性質が違うため、円グラフを使って見える化の予定。
💬 サンキー図っていうのか。
コミュニティ運営の課題
人が足らない。
オンボーディングが十分にできていない課題がある。
ただ、熱意はみんなあるし、
さまざまな方がコミュニティに参加している。
デジタル庁の取り組み
デジタル庁もダッシュボードを作っている。
行政では扱いにくいところもあるため、
民間だからできることもある。
副作用をどこに置くか問題
スライド：https://speakerdeck.com/koxya/where-to-put-side-effects-a-decision-tree-with-object-oriented-design
オブジェクト指向で整理する設計判断ツリー
商品情報の取得や、
ランキングの更新を自動化するシステムの開発をしている。
💬 これの内容、気になるなー。
副作用が生む問題
副作用の大変なところは、
処理順に依存すること、
コンテキストに依存することなど、
暗黙知を生み出す点。
ライフサイクルフックによる分離
ユーザー登録前後で、
バリデーションやログ送信などをやるときに、
createActionではUserをcreateするだけにして、
beforeActionやafterCommitなどを使ってフックしていく。
テストがスタブだらけになるという問題もある。
オブジェクトの存在条件を守る
ホテルの予約なら、
予約者がある、チェックイン < チェックアウトなど。
存在条件がライフサイクルでフックされていないと、
そのアカウントが存在条件を満たすかを
さまざまな場所でチェックしないといけなくなる。
Rubyならバリデーションなどを使ってチェックする。
副作用が失敗したら不完全な状態になるか？
バリデーションが失敗したら不完全な状態になる時は yes。
他の関心へのメッセージ
OrderしたUserにPointを付与する。
オブジェクトの状態を他の関心に伝える。
ライフサイクルにフックさせると、
afterCommitでOrderからPointへの依存が生まれる。
テストではOrderインスタンスも作ることになる。
adminからの注文ではPointを付与しないなど、
さまざまな条件にも対応する必要がある。
💬 自分ならafterCommitでやるのかなるほどなと納得しちゃうかも
YAGNIと抽象化のバランス
YAGNI：必要となるまで機能を追加しない。
良かれと思って機能を追加しない。
だからといって、
抽象化などをさぼっていいわけではない。
callback地獄の問題
callbackは使いすぎるとカオスになる。
テストがしづらくなる。
いじった時に意図せず副作用が出る。
オブジェクトがライフサイクルにフックする場合は、
他の関心が少なく安定しているケース。
今後増える予定もない場合、
コードへの見通しを立てやすい時。
イベント駆動設計への注目
データベースの制約はないが、
ユースケースとして一貫性を保つ。
CheckOutモデルを作って、
OrderとPoint付与を実行する。
うっかりでOrderとPointの整合性を壊せる。
💬 Orderの状態を集計して、
最終的な持っているPointを算出できそうなら、
DBとか使わずにイベントでいいのかもな。
運命をともにするモデルのポイント
運命をともにするパターンでは、
データベースに制約を持たせず、
イベントをモデルとして対応する。
それでもCheckOutに副作用を集めすぎると辛くなる。
SOLIDの原則を守る。
CheckOutとMailerなら、Mailerのほうが詳細。
読み出し側を抽象に依存させる。
interfaceを使って依存を減らす。
新卒社員がWebViewをビルドしてパスキー対応しようとした話
スライド：https://www.slideshare.net/slideshow/webview-yoshiiwa/285100550
外部サイトのWebのパスキーを
WebViewベースのブラウザで使えない。
それを調査した過程の話。
WebViewが信頼されない問題
WebサイトがWebViewを信頼してくれない。
DAL（証明書）をWebサイト側に置く必要があり、
Webサイトを自分が管理していないとできない。
AOSPを読むという選択
AOSP（Android Open Source Project）を読んで調査すること。
WebViewのWebauthSupportに注目。
APIにはなし。
CHROME, CHROME_3PP_ENABLEが使えることがわかった。
実際にWebViewをビルドしてみることに。
しかし、WebViewをビルドしたものは公式でビルドされたAndoroid OSでは動かない。
そこでLineageOSをビルドして、そこに改造WebViewを組み込んで、動かすことに。
LineageOSのビルドにもいろいろあったが割愛。
最終的にはそれでも動かなかった。
React 19でつくる「気持ちいいUI」
スライド：https://speakerdeck.com/himorishige/react-19detukuru-qi-chi-tiiiui-le-guan-de-uinosusume
楽観的UIのすすめ
DBの更新が行われる前にUIにフィードバックすることで、
処理を早く見せる。
ただ、早すぎると不信感などが生まれる場合は、
Artificial Delayを使う。
💬 Artificial Delay は3Dグッズ作成機能では話にあったやつだ。
名前がついてるのか。
Lobar illusion効果というのもある。