プロポーザル

4月に行われたCloudflareのDeveloper WeekではデータベースやAIの製品発表に隠れるように「JS RPC」という機能が追加されました。JS RPCでは、Cloudflare上のWorkerからWorkerを呼び出すのがRPCで行うことができるようになる。これはセキュリティと開発者体験を向上させます。外部Web APIを叩く時、一般的にはエンドポイントのURLと認証トークンを書きますが、それをRPCで、それもJavaScriptネイティブで呼び出すことができる。CloudflareではD1やR2などのミドルウェアをBindingsという方法で呼びますが、つまりそれを自分で作れる。例えば、Discord APIを呼び出すBindingが作れるし、もしかして、ユーザーが作ったカスタムBindingsが流通するMarketができるかもしれない！そんな楽しい話をします。

最近、テクニカルライターとして Docusaurus と睨めっこしています。
ドキュメントを提供する上で、時にはインターネットにアクセスできないお客様のためにPDF化が必要になります。
Docusaurus には PDF を生成する 3rd party のプラグインもありますが、Docusaurus自体のバージョンアップに追従する難易度や、メンテナビリティを考慮して採用を控えました。
代わりに、E2E テストツールである Playwright を悪用しています。
Playwright にはテストのスナップショットを生成するためにPDFを生成する機能が付いています。
嬉しいことに撮影範囲はセレクタで絞り込めます。
このトークではそのような Playwright の目的外利用をどのように実現したかお話しします。

GraphQLクライアントとして、Apollo Clientを使用している事例は数多くあると思います。
他の有力な候補としてRelayやurqlが挙げられますが、それらと比較した場合、機能面や開発者体験においてApollo Clientが若干遅れを取っている印象がありました。
しかし、直近のApollo Clientのアップデートや周辺ライブラリの進化により、その差はかなり縮まりました。

このトークでは、その変遷を過去3年間の開発における事例を交えながら紹介し、さらに今後の展望についても話します。

具体的には下記の内容を紹介する予定です。

• Apollo Clientについての簡単な説明
• ライブラリ選定と開発スタイルの変遷の事例
  • graphql-anywhere、client-preset、useFragmentなど
• 直近の大幅なアップデートと今後の展望

esbuildやswcの登場を皮切りに、近年のフロントエンドツールはJavaScript（TypeScript）以外の言語で実装されることが増えています。特にRustはゼロコストの抽象化機能を備えており、アルゴリズムの複雑さとメモリ割り当てに気をつけるだけで良く、パーサーやASTを用いた網羅的な実装が頻出するフロントエンドツールの開発に向いていると考えられています。

oxcはハイパフォーマンスなフロントエンドツールのコレクションであり、biomeやrolldown、rspackなどの実装で使用されています。

このセッションでは、oxcがなぜ高性能なのか、その背後にある技術を解説します。また、oxcがフロントエンドツール開発の未来をどのように変えていくか、その可能性についてもestreeなどの既存技術との比較を通して探ります。

storybookをベースにVisual regression testやアクセシビリティーのテストができるらしい！
ぜひやりたいが手元にはSPAではなくtemplate engineベースのMPAしかない！そんな時に役立つテクニックをご紹介します。

近年、フロントエンドにおいて、Rust製のツールが増えてきました
一方で、フロントエンドエンジニアの多くはJavaScriptやTypeScriptが中心で、Rustはあまり馴染みがないのが現状です
私自身、スクリプト言語を中心に使ってきた普通のWebエンジニアですが、フロントエンドツールチェインをより深く理解し、パフォーマンス改善やOSS貢献ができるようになりたいと考え、Rustの学習を始めました
簡単なCLIツールを作成したり、普段Node.jsで書いているような処理をRustで置き換えたりすることで、少しずつ言語に馴染んでいきました
このトークでは、私の入門の過程をご紹介しながら、Rustを学ぶメリットについて考察します
Rustに興味はあるけれどまだ始められていない方にとって、入門のきっかけになれば幸いです

昨年度、弊社では新規プロダクトの開発プロジェクトがスタートしました。
その際、技術スタックの変更—Vue.jsからReact(Next.js)への変更を決定しました。
しかし、Reactに関する実務経験があるメンバーは社内におらず、専任のデザイナーも不在であるという二重の課題に直面しました。

そのような状況下で約1年間のプロジェクトをどのように進め、完遂させたのかを共有します。
・設計(コンポーネント設計)
・開発フロー(デザインチェック)
を中心に、下記記事[1]をよりパワーアップさせ、プロジェクトで得られた知見を詳細にお話しさせていただきます。

特にスタートアップや新規事業を担当するスモールチームに関わる方にとって、
開発プロセスの改善や技術選定の参考になれば幸いです。

[1]https://zenn.dev/recustomer/articles/9c50a5c21f3000

ここ数年、新卒研修でWebプログラミング講師を担当しています。
研修は受講者の経験レベルもバラバラで時間も限られますが、実施するからには次のことを学んで欲しいと思いました。

• ブラウザはアクセスしたURL以外にも、タグに書かれているURLにアクセスする
• サーバーは特定のパスに該当するアセットやデータを返す
• ヘッダーフィールドはTCPの上でHTTP通信を実現するためにとても重要
• サーバーは動的なページを返せる

これらをなるべくWebの仕様そのものに沿って教えるとなった時に、Rubyが適していることに気づきました。
RubyはTCP通信や動的HTML生成を標準ライブラリだけで素直に実装可能で、HTTPはリクエストラインから仕様通りに書き下せて、Macに最初から入っています。
このトークではRubyを使ってWebの基礎を学ぶのにちょうど良いサーバーを作るところをお見せします。

みなさんはブロックチェーンアプリケーションを開発したことがありますか？
おそらく開発したことがない方が大部分だと思います。

ブロックチェーンと言うと投資や投機、ファイナンス領域で使うものでは？
スマートコントラクトとかブロックチェーン特有の概念が多くて難しいのでは？
特にブロックチェーンである必要がないんだけど？

などなど、いろいろ思って手を出さない領域だと思います。とてもわかります。
ただ、それはとても勿体無いです。特にフロントエンド開発においてはデータの保存先の選択肢が1つ増えるので、一度は触って知って欲しい領域です。

そこで、本セッションではSolanaというチェーンを題材に、チェーンの概要、扱うメリット、開発するときの注意点などをもとに、ブロックチェーンアプリケーションの楽しさ、魅力を紹介します。

2023年の12月、『timer.team』というWebアプリをリリースしました。開発にはTypeScriptを採用し、ランタイムとしてDenoを、フロントエンドフレームワークとしてFreshを選択しました。開発記録をまとめた記事[1]には注目が集まり、Zennのトレンドにも掲載されました。

本発表では、Denoのエコシステムを活用した開発の具体例を踏まえて、Freshの選択により大きなメリットを享受したことを示します。また、Deno Deploy上での実際の運用事例、BroadcastChannelからDeno KV watch API [2]へのリプレース結果など、Zennの記事のその後についても発表します。

[1] https://zenn.dev/lef237/articles/8e4eb3112928d6
[2] https://deno.com/blog/kv-watch

昨今のエッジ進化は、フロントエンドを学ぶ上で避けて通れない存在となってきています。
これまでは単純にCDNに画像を配置していた時代から、エッジを挟むことで画像に対するリクエストにも様々処理（夢）を挟むことも可能となりました。

このトークでは、そんなリソースに対するリクエスト処理で、レスポンス速度はCDN並みに早く、そこに色々な夢（処理）を詰め込むケースをいくつか紹介します。
以下にいくつかサンプルのケースを掲載しておきます。

・画像変換をエッジで行う
・リソースに対するリクエスト数をエッジで計測する
・エッジでHTML,CSS,Javascriptの処理を書き換えてレスポンスする
・署名URL（Cookie）でリソースをエッジで守る
・etc...

参考
https://zenn.dev/oliver/articles/cloudflare-meetup-2023-10-06

皆さんも日頃からBasic認証を使っていると思います。
しかし実装がどうなっているかはご存知でしょうか。
大体のフレームワークのプラグインを使わずに自前で実装するとすると何が必要になるがご存知でしょうか。
Authorizationヘッダーの構成要素に名前や仕様が存在していることはご存知でしょうか。
Basic認証はHTTP Authenticationの枠組みの一つでしかないことはご存知でしょうか。
ブラウザにUsernameとPasswordの入力画面が表示されるのは、どの仕様のおかげでしょうか。
その仕様に準拠しないとどのようなバグを引き起こし、ユーザーにどのようなワークアラウンドを要するかご存知でしょうか。

このように一見簡単なBasic認証ですが、仕様を理解することで初めて見えてくる世界や、調査や解決できるバグもあります。
このトークでは上記の疑問に対する答えを速習します。

概要:
このセッションでは、MVCフレームワークに慣れたPHPエンジニアが、どのようにしてLaravelのBladeテンプレートエンジンを使用してWordPressサイトを構築したかを紹介します。従来のWordPressの開発環境に馴染めなかったエンジニアが、Bladeを使うことでどのように開発プロセスを効率化し、再利用可能なUIコンポーネントを作成し、コードの冗長性を減らしたかを紹介します。

具体的な学びのポイント:
Bladeの導入: BladeをWordPress環境に統合する際の技術的なステップと必要なツール。
開発効率の向上: 再利用可能なコンポーネントの作成と、維持管理の容易さについての実例。
挑戦と解決策: WordPressのエコシステムに逆らうことで発生した問題点と、それにどのように対応したか。

近年、Webフロントエンド上で3DCGモデルを動作させる技術の注目度が上がってきてます。
本セッションではThree.jsのWebGL技術を用いてReact上で3DCGモデルを動作させることについて話します。

▼ こんな人が対象者

• Webブラウザで3DCGモデルを動作させたい人
• Three.jsを利用したことがあるが、Reactとの組み合わせで悩んでる人
• Unityの実装経験はあるが、Three.jsは未経験の人

▼ 内容

• React関数コンポーネントの中で動作させるThree.jsについて
• 3DCGモデル・画像・動画・アニメーションの描画方法について
• Three.jsの周辺機能を提供するカスタムフックの作成について
• 「Webフロントエンド x 3DCG」のこれからについて

このセッションではReact RouterやTanStack Routerなど
ReactのSPAアプリで導入可能なルーティングライブラリについて話します。

▼ こんな人が対象者

• Reactのルーティングライブラリについて知りたい人
• 普段、Next.jsやRemixなどのフレームワークを利用しており、ルーティングライブラリについてよくわからない人

▼ 内容

• React RouterやTanStack Routerなどの主要なルーティングライブラリについて
• 「File Based Routing」 VS 「Directory-Based Routing」の話
• Next.jsやRemixなどのフレームワークとの組み合わせについて

私の自社プロダクトではご利用ユーザーの特性上
2024年現在でもガラケー（フィーチャーフォン）やガラホ（ガラパゴス型Androidスマートフォン）をサポートしております。
このセッションでは、これらのレガシーデバイスに対してどのようにサポートを続けてきたかについて話します。

▼ こんな人が対象者

• 私と同じようにガラケー・ガラホのサポートを強いられている人
• ガラケー・ガラホのサポートについて興味がある人

▼ 内容

• レガシーデバイスのWebブラウザとの向き合い方
• 厳しい制約の中で実装するJavaScriptについて
• ガラケー・ガラホからのリクエスト識別方法について

このセッションでは、PHPバックエンドエンジニアがフロントエンドの最新技術のひとつである、NextJSへの入門を試みる過程を紹介します。

特に生成AI技術を活用して英語のドキュメントを理解し、コーディング時の疑問は都度解決するという方法に焦点を当てます。
実際に、GatsbyJSで構築したブログサイトをNextJSへ移行したときのことを取り上げ、バックエンドエンジニアがAI技術と共にどうフロントエンド技術を理解していったかを掘り下げてみようと思います。

昨今フロントエンドにおける自動テスト手法が注目を浴びています。
その中でテストが存在しない既存のプロジェクトはテストとどう向き合うべきでしょうか。

本発表ではテストが書かれていない既存フロントエンドプロジェクトが抱えていた課題と、それに対して「どのように」「どんな」自動テストを導入したかを話したいと思います。

主な内容

• プロジェクトが抱える課題
  • 人的リソース
  • ライブラリバージョンアップなどリスク
  • リリース作業のコスト
• Next.js (Page Router) で書かれたコードに自動テストを導入する
  • 静的解析
  • Jest, React testing library を用いた Component のテスト
  • Playwright による Storybook を再利用した Visual Regression Test

Swift!Swift!ぅうううわぁあああん!!!

んはぁっ!Swiftたんの型安全な世界をWebフロントエンド開発でも体感したいお！
SwiftWasmたんを使えば、フロントエンドでSwiftたんを使うことができる…?きゅんきゅんきゅい!

ぐああ!生成されるWebAssemblyバイナリのサイズが大きいから、Swift ちゃんをWebフロントエンドで使うのは 現実的 じ ゃ な い?にゃああん!うぁあ!

ちきしょー!やめてやる!現実なんかやめ…て…え!?見…てる?SwiftWasmちゃんが僕を見てる?
よかった…世の中まだまだ捨てたモンじゃないんだねっ!
いやっほぉお!!僕にはSwiftWasmちゃんがいる!やったよケティ!ひとりでできるもん!!

本トークでは、現時点のSwiftWasmは どこまで・何ができるのか探究することを試みます。

Swiftといえば、iOSやmacOSアプリを開発する言語だと思い込んでいませんか？

実はLinuxやWindowsでもサポートされている、汎用プログラミング言語です。
意外と知られていない事実ですが、Swiftは、「さまざまな用途で使える最高の言語を作る」という、とても野心的な目標を持って開発されています。

さて、SwiftWasmというプロジェクトがあります。
これは、WebAssemblyでSwiftを使えるようにするというプロジェクトです。
つまり、ブラウザ上でSwiftを走らせることができます！！

本トークでは、サーバーサイドSwiftとSwiftWasmを使って、SwiftメインでWebアプリケーションを作った汗と涙に溢れる体験を共有し、Swiftを中心としたWebアプリケーション開発の可能性を探ります。