Skip to content

Instantly share code, notes, and snippets.

@hushin

hushin/20231118164904-jsconf_jp_2023.org

Created November 20, 2023 01:01
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save hushin/518326bbb729d1f34f7fb22deb45d2aa to your computer and use it in GitHub Desktop.
Save hushin/518326bbb729d1f34f7fb22deb45d2aa to your computer and use it in GitHub Desktop.
Download ZIP
Raw
20231118164904-jsconf_jp_2023.org

JSConf JP 2023

概要

セッション

Opening

  • 古川さん

[#B] There and Back Again: A Proposal’s Tale (yulia-startsev-1) (room: A)

How does an idea became part of the JavaScript language? Let’s follow a JavaScript feature from its initial specification to a complete implementation in the SpiderMonkey engine. You will learn about the standardization process, how to read the specification, and how to implement the feature yourself.

  • TC39の進行役、SpiderMonkey
  • JSいろいろ使える、プラットフォーム、web, Node.js
  • 思考の道具としての表記法
  • 単にコンパイラを作成するだけではありません
  • mozilla, spidermonkey

TC39

stage

  • stage 0 だれでも企画書を書いて提案できる
    • filter の例
      • ドアの問題
        • pull, push
      • インターフェースがわかりにくい
  • stage1 委員会に提出
    • 文献分析
    • その他の選択肢
      • 役に立たないと却下
      • groupBy のように新しい機能があると採択
  • stage2 Draft
  • stage3 ブラウザが実装開始、コメントを出す
    • コンパイラ構築の段階的アプローチ
    • self-hosting
      • JSの機能をJSで書く
    • コードを書いてみよう
      • c++ マクロ
        • 追加するだけでは関数ではない
        • 関数の実体を書いていく
      • 仕様をもとに実装していく？
      • Type
      • Specification Type
        • normal completion など
      • question mark ? の意味は？
        • Notaional Conventions
      • EcmaScript の仕様の読み方を説明してるが知らないとついていけない
      • c++ のコードで説明。コメントがあるので読めた気になる
    • 実装すると欠陥が明らかになる
      • sugar.js ライブラリ issue
        • まず連絡してみる
          • 失敗→rename
          • 別のリグレッションが発生
          • 仕方ないので Object.groupBy へ
            • stage2 に降格
  • stage4 完了！

Web Internals: Mastering the JavaScript Engine (anirudh-sharma-1) (room: A)

For every developer, it’s really essential to understand the internals in order to be aware and write optimized code. With a whole existing and upcoming ecosystem of libraries and frameworks around JavaScript, the need for thorough understanding of code execution on the web becomes more relevant. This knowledge also helps you to better understand and distinguish technologies like WebAssembly from JavaScript.

Attend this talk to get an in-depth overview of the JavaScript engine and learn how it can help you as a developer to write more optimized JavaScript code. You will learn how exactly your high-level code is converted to bytecode and then to the optimized machine code with the magic of the V8 engine.

The key session highlights include:

  1. Intro to JS engines and the V8 engine evolution
  2. Abstract Syntax Tree (AST)
  3. Ignition, Bytecode and Turbofan
  4. Hidden classes and Inline caching
  5. Garbage collection
  6. Writing optimized code

[#B] Deep dive into Biome (daiki-nishikawa-1) (room: B)

Biome は、Rome を fork して始まった Web 開発に必要なツールチェーンを開発するプロジェクトです。現在は、JavaScript、TypeScript、JSON の formatter や linter を提供しており、Vercel の新規プロダクトにも利用されています。

今回のトークでは、Biome の直近の開発体制やリリースを紹介しつつ、Rust で実装されている Biome の内部について詳しく解説します。コアコントリビューターの一人として、Rust でJavaScript に関するツールを作る面白さやコントリビュートを歓迎している雰囲気などを伝えられるトークをしたいと考えています。

現時点で具体的に考えている発表内容は次の通りです。

  • Biome の直近の開発体制やリリースの紹介 プロジェクトの governace をベースに開発体制について紹介します。直近のリリースの紹介に加えて、コアチーム内で進行中の実装 (CSSのサポートなど) の近況についても紹介します。
  • Biome の内部アーキテクチャの解説 内部で利用されている CST (Concrete Syntax Tree) の特徴などについて紹介します。構文木は Rust の LSP (rust-analyzer) の実装で利用されている rowan をベースとしたものになっており、この点にも触れながら紹介するつもりです。
  • Biome での linter の実装例の紹介 linter の実装方法について、簡単なルールを例に具体的なコードを紹介しながら解説します。

Biomeとは

  • 今は linter と formatter
  • rome の fork
    • rome メンバーレイオフで開発が止まった
    • コミュニティベースで引き継ぐ
  • 最近
    • new lint rules
  • ガバナンスを作った
    • コントリビューターを増やしたい
    • open collective
  • css support
  • romeから乗り換えが始まっている
  • 誰が使っている？
    • vercel v0のコード生成
    • Ant design
    • unleash
    • tamagui
  • 会場で使ってる人は一人だけ

他のツールとの違い

  • なぜつかっているのか
    • Advantages
      • fast
      • simple
      • TS, JSX
      • error resilience
        • ESLintは invalid syntax があると解析をやめる
  • parser 内部解説
    • green tree と red tree を作る
      • 壊れててもASTを作る
    • green tree
      • imutable tree
    • red tree
      • mutable tree
    • ESTreeとは別のAST
    • bogus nodeで壊れてる箇所を表現
    • red-green tree
      • 構文木から元のコードを戻せる
      • Rowan を fork
    • フルスクラッチ
      • lightning css とかと別

linter code

  • example: enforce foo bar
  • ESLint の知識が活きる

[#C] LLM全盛時代の開発プラクティス (baseballyama-1) (room: C)

2022年11月30日にOpenAI社からChatGPTが発表されて以降、LLM全盛時代に入ろうとしています。 私は、LLMはソフトウェア開発に大きな変化をもたらすと考えています。

私は株式会社Flyleでソフトウェアエンジニアをしています。私は直近半年以上、業務としてLLMに専念してきました。 そして、既に自社製品にLLM (や機械学習) を組み込んだ機能をいくつもリリースしました。(今後も継続的にリリースします)

その一方で、私はLLMを使用した開発チームの生産性向上にも注目しています。 優秀な少人数のエンジニアチームが、LLMによってその能力を10倍エンハンスすることができたら、その企業の競争力が大きく高まることは想像に難くないと思います。

このセッションでは実際にLLMを使用して生産性を向上するための技術を発表します。 具体的なコンテンツは以下です。(最新の調査内容をお届けしたいのでコンテンツは更新される場合があります)

1: LLMは “新人” だと考えるとわかりやすい (1) なぜ LLM は “新人” なのか (2) “コードレビュー” といった曖昧で複雑なタスクをLLMに依頼するのは現実的ではない (3) 「人間Aが実装 -> 人間Bがレビュー」という構造から「LLMが実装 -> 人間Aがレビュー」という構造をいかに作り出せるかがキーポイント 2: LLMのサジェストを最大化するためには とにかく “統一感” が重要である (1) なぜ統一感が重要なのか (2) 統一感をもたらすための技術 (Prettier / ESLint / Stylelint / カスタムルールの実装) 3: LLMによって技術選定に変化はあるか (1) LLMが学習済みの2021年9月以前に存在した技術を優先して使うべきか? (No) 4: コーディングガイドを常に開いておこう (1) GitHub Copilot の仕組み (2) LLMでの使用を前提としたコーディングガイドの書き方 (3) コーディングガイドを開いた時と開いていない時でサジェストにどのような違いがあるか 5: (番外編) (経験を元に感じた) 製品にLLMを組み込む際のポイント

(JSConf JP 2023) LLM (大規模言語モデル) 全盛時代の開発プラクティス - Speaker Deck

Machine learning with Javascript using Tensorflow.JS (aileen-villanueva-lecuona-1) (room: A)

Machine Learning helps give new ways of solving problems that are not possible with traditional computational approaches. However most of the available libraries are with R, Python or C++. According to Stackoverflow: 2022 marks JavaScript’s tenth year in a row as the most commonly used programming language. Tensorflow helps bring high-performance ML and attention to this vast community to continue the journey of solving problems with Javascript and Machine Learning.

Participants will learn basics of AI and machine learning, how to train and deploy machine learning models and all machine learning capabilities available on a web browser and Node.js for server-side and back-end development with Tensorflow.js .

[#B] Build and Publish in 2023 (mizchi-1) (room: B)

JS のビルドと配布は、commonjs と webpack 以降、複雑化しつつ洗練されてきました。現代の開発者は複雑なツールチェインを駆使して開発体験を充実させつつ、ビルド速度とランタイムパフォーマンスを両立しないといけません。このセッションでは素朴なファイル結合の時代から現代の静的解析によるバンドルと最適化を振り返りつつ、 現代の vite, turbo, deno, RSC 等が何をやっているかを解説します。

https://jsconfjp-slide.pages.dev/

  • ツールチェーンで消耗
  • ランタイム仕様を再考しViteやNext.jsについて考えたい

ランタイム

  • 昔ふりかえり
    • ES5 Object
    • CommonJS
      • 構文ではなく関数ユーティリティ
    • ES Modules
      • ファイルスコープの導入
      • インポート先をどのようにロードするか実行環境依存
      • 問題：RTT
  • 今の仕様なら確認できるか？
    • modulepreload
      • 深さ問題は解決しない
      • モジュール数>100 or 深さ>5 ならバンドルした方がいい
    • HTTP 103 Early Hints
      • 先読みできるが、事前に依存解決が必要
    • importmaps
    • Module Declaration
      • stage2
      • TSとかぶる
    • HTTP Imports
      • 改ざんに弱い

Toolchains

  • 歴史
    • Closure Compiler 2009
    • browserify 2011
    • webpack 2014
      • チャンク分割
  • webpack 普及と課題
    • 良いデフォルト設定の不在
    • CPU/FileIOへの負荷が激しい
      • Docker on Mac 上で低速化
    • ESM対応が後付
  • 以降
    • Rollup
      • ESMファースト
      • TreeShakeによるDCE
    • esbuild
    • Vite
      • index.html を入力とするバンドラ
      • zero-config
      • 実体はesbuild
      • No Bundle
        • 開発時はバンドルしない
      • 使用率49%まで上がってる
    • Turborepo
      • ワークスペース環境のビルド最適化
  • まとめ
    • 出力が高度化
      • zero config

SSR

  • Next.js
    • SSR/CSRのhybrid フレームワーク
    • 発明
      • filesystem routing
        • SSR + CSR hydration コードを同時に生成
      • DataLoader
        • データの受け渡しをprops
      • RSC
  • Vite SSR
  • Qwik
  • まとめ
    • アーバサイドにチャンクを投げる

結論

  • ビルドツールチェインの争点
    • Next 以外のRSC導入時に混乱が予想
    • React以外でのSC概念の輸入
  • 崩壊するzero-config
  • 自分が本当に必要なものは手を動かさないとわからない
    • Backbone → React

Micro frontends in Action! (peter-eijgermans-1) (room: C)

Microservices have gained significant popularity in recent years as organizations seek to overcome the limitations of monolithic backends.

However, the challenges of ‘monolithic frontends’ persist for many companies.

In this session, Peter Eijgermans delves into a growing trend that aims to break down front-end monoliths into smaller, more manageable pieces. This architectural approach not only enhances team effectiveness and efficiency but also unlocks new possibilities.

Peter begins by sharing an engaging anecdote of his adventure with a rhinoceros in Nepal, drawing parallels with the concept of monoliths that need to be overcome before embracing micro frontends. The presentation then focuses on establishing a robust Micro Frontends architecture, providing attendees with valuable insights into best practices, determining when and why to utilize micro frontends, and taking the initial steps towards implementation.

Moreover, Peter showcases strategies for converting a monolith into a micro frontend application, offering practical guidance and demonstrating real-world scenarios.

One of the key aspects covered is establishing seamless communication between Micro Frontends, ensuring smooth collaboration and integration within the architecture.

Game Development with JavaScript (christoph-nakazawa-1) (room: A)

Let’s dive into how to build video games with JavaScript! This talk will give an overview of game development with JavaScript by demoing Athena Crisis, a game entirely written from scratch with JavaScript.

[#B] フロントエンドリアーキテクチャリングと開発チームのスキルトランスファーにおける9ヶ月間の奮闘記 (wakamsha-1) (room: B)

2023年1月から9月にかけて弊社 BtoB web アプリケーションのリアーキテクチャリングプロジェクトにフロントエンドのシステムアーキテクトとして参画し、技術選定から開発メンバーのスキルトランスファー（育成）、果ては包括的な開発プロセスの改善までと幅広く支援してきました（2023年11月現在も進行中）。そこでの奮闘で得た学びと新たに浮き彫りとなった課題についてご紹介します。

  • マネーフォワード
  • FE14年
  • FE推進グループ
  • RubyとRails主軸、多くのアプリ
  • Rails からフロントエンド分離
  • チームはモダンなFE開発のスキルを習得する
    • 現場がつくる、自走してもらう
    • 単なる表層的なところではなく、選定できる思考を育てる
  • クラウド会計Plus
    • ハードフォークして作ってた
    • Rails内にReact,TSがあったのを分離、APIはGraphQL
    • 9ヶ月フルサポート

実践

  • 丸暗記を徹底的に排除する
    • なぜ、革新に絞って教える
  • 一度に多くのことを教えない
  • 覚えることはたくさんある
    • 段階を踏んで教える
      • 状態管理、Reactのものから
      • graphql Fragmentが必要になってから
      • CSS Flexbox → grid
  • ペアプロで小さな成功体験をたくさん積んでもらう
  • 早期から包括的な自動テスト・ビルドを充実させる
    • 開発効率を下げない
  • 早期からRenovateを導入
  • ドキュメンテーション
    • README
    • 意思決定の過程をあとから辿れるようにする
      • design doc
    • JSDoc

支援活動を終えて

  • 意思決定者（PO）の開発現場に対する理解力の重要性
  • 技術に対する探究心の重要性
  • 反省
    • 実験用リポジトリがあると良かった
    • Design Doc と ADRs に対する理解が不足、整理されていない

[#C] TypeScriptで型定義を信頼しすぎず「信頼境界線」を設置した話 (himeno-kosei-1) (room: C)

TypeScript は静的型付けを持つ言語なので、外部からの入力について CやC++、Goなどと同じぐらいの安全性があると思いがちです。その結果、「ユーザーからの入力」や「APIによるデータの送受信」「UI側での情報更新」などで型定義を信頼しすぎて、入力値の確認を怠っていませんか？

HireRoo では型定義を信頼しすぎた結果、失敗してしまった事例がありました。その失敗事例では型定義だけでは防げない事象があり、サーバサイドはもちろん、クライアントサイドでもバリデーションを行う必要がありました。

本登壇では、型安全な処理を実現するために必要な値の信頼できる区間「信頼境界線」を設置し、信頼できない区間からやってくるデータを入念にテスト出来るようにしたり、境界を明確化することで意思疎通が早くなった話など、実際に改善をおこなった事例を話します。

Beyond the Web of Today (kenneth-rohde-christiansen-1) (room: A)

At Intel we work on the forefront of innovation as our hardware roadmaps are defined years ahead of release. This means that we need to make sure that the web platform takes advantage of new hardware capabilities as they are released or shortly after. This ranges from enabling new form factors to taking advantage of hardware accelerators.

In this talk we will discuss some of the new innovations that Intel is bringing to the web, such as WebNN, which enables access to fast neural network and machine learning capabilities; Web GPU and Compute Pressure, a new API enabling better user experience and bringing adaptive compute capabilities to the client, just like adaptive streaming has improved streaming use-cases by adapting to live network conditions.

[#B] Next.js App Router クライアントキャッシュの仕組み (akfm-sato-1) (room: B)

Next.js App Routerのクライアントキャッシュの仕組み・実装・課題について発表します。

  • 仕事は Pages Router
  • App Router に興味あり

Router Cache の複雑さ

  • App Router
  • Router Cache
    • クライアントでのキャッシュ
    • 絶対に必要
    • デフォルトでprefetch する。disableにすることもできる
    • dynamicは静的なのを先に返す
      • ページにアクセスしたら動的、ページ全体のものをレンダリング
  • rendering
    • static/dynamic
      • 基本はdynamic
    • Link prefetch props
    • state ごとに挙動が異なる
    • 取得からの時間
  • cache の purge が複雑
  • cacheがあると intercepting routes が機能しない

App Routerのいいところ

  • Server Components
  • Nested Layout
  • Server Actions

今後

  • 複数majorバージョンにおいてPages Routerのサポートは継続
    • その後のことは明言していない

[#C] Building Text Containers in Canvas :) (aakansha-1) (room: C)

Text Containers are one of the most widely used features when it comes to whiteboard, isn’t it? In my talk, we will be diving into how these text containers work under the hood in Canvas and I will also be sharing my experience building text containers in [Excalidraw](https://excalidraw.com/) - A virtual free Open-Source collaborative end-to-end encrypted canvas based editor for sketching hand-drawn diagrams.

Trusted Types: DOM XSS Proteciton at Scale (kian-jamali-1) (room: A)

DOM XSS continues to be the most critical threat to web security. Our current best defense against DOM XSS is Trusted Types, a browser-based runtime feature to limit the uses of DOM APIs (and limit the possibility of DOM injection). We will discuss our approach to using Trusted Types at Google to protect billions of our users, the challenges of backporting Trusted Types compatibility to hundreds of webapps, and our approach to making the entire JS ecosystem safer with Trusted Types.

[#B] Next.js App Router でのMPAフロントエンド刷新 (hajime-mugishima-1) (room: B)

現在フロントエンド領域では React Server Components とそれを利用する Next.js App Router が登場し、根底となるアプリケーション設計にも大きく影響を与えています。技術選定やマイグレーションの面でも悩みの多い過渡期を迎えていると思います。

そんな中、サイボウズで提供するプロダクト「サイボウズOffice」では、Next.js App Router を採用したフロントエンドの基盤刷新に取り組んでおり、すでに数画面のリリースを完了しています。

Next.js App Routerによって大きく変わったキャッシュ・テスト・エラーハンドリング・Server Actionsなどについて実際に現場で採用して得られた知見や課題に加え、認証を伴うMPAからの刷新の視点でNext.js App Routerがどのように扱えるかなどをご紹介します。

https://speakerdeck.com/mugi_uno/next-dot-js-app-router-deno-mpa-hurontoendoshua-xin

  • サイボウズOffice
    • 完全独自のスクリプト言語
    • ES5 & jQuery
    • フロントエンド刷新
      • App Router
      • CSS Modules
      • React Spectrum
      • TS
      • jest / playwright

Caching

  • 前の発表で習った
  • グループウェアの刷新という大前提、基本的には最新データの表示
  • 意図通り無効化できないとリスク
  • Dynamic Functions とキャッシュ
    • 認証/認可にCookieを用いるとキャッシュされない？
      • デフォルト挙動ではそう
      • 個々のオプションで変えられる
  • 無効化
    • 設定で無効化
    • 明示的に無効化していく

SC & CC

  • use client は 境界
  • 両方使いたいコンポーネント
    • ボタン
    • イベントハンドラを optional props で受け取る
      • next/link の Link コンポーネント 参考
  • 基本的にはSC前提

Storybook

  • Server Components未対応
  • Presentational Componentの分離

Testing

  • testing-library 未対応
  • 関数として直接実行すればテストできなくもない
  • experimental , playwright
  • E2Eを主軸にした
  • 実行コスト

Server Actions

所感

  • MPA刷新での体験は良い
  • Undocumentedな仕様が多い

Mastering Cryptography Fundamentals with Node’s crypto module (yonatan-mevorach-1) (room: C)

Do you know that meme of Homer Simpson trying to hide in the bushes? That’s how I would feel when my coworkers would discuss asymmetric encryption, certificate signing, salting, and crazy-sounding acronyms like PBKDF2. After years of trying to ignore this problem, I finally decided to do something about it. But rather than digging into the subject via textbooks and pseudo-code, I decided to research the massive amount of functionality that is offered by Node.js’ built-in `crypto` module. Then I worked my way backwards to understand what each function does, what underling security best-practice it’s based on, and when it’s appropriate to use it. So if you’re like me then step out of the bushes, and join me in this talk to learn the fundamentals of protecting information in a practical way with Node.js

パスワードレス認証がもたらすユーザー体験の向上と考慮点 (workshop-auth0) (room: D)

アプリやWebサービスの開発において必要不可欠な認証がユーザー体験の改善案として注目されています。このセッションではWebAuthnやPasskeysによって実現されるパスワードレス認証によってユーザーの体験がどのように変化するのか、また、導入時に考慮するべきことは何かについてみなさんと考えてみたいと思います。

Static Analysis: Shockingly Awesome! ⚡️ (josh-goldberg-1) (room: A)

Wouldn’t you love to automatically zap code bugs before releasing to production? How about before your code even gets run? Static analysis tools scrutinize your code as you write it - giving you blazing fast feedback at development time. We’re going to go into how that works, why it’s useful, and -best of all- how to enable the best configurations for ESLint, TypeScript, and their associated tooling in your app.

In particular, we’ll cover:

  • The tooling differences between formatters, linters, and type checkers
  • How to appropriately set up each of those tools for local development and CI/builds
  • A brief overview of using recommended rulesets from ESLint and TypeScript-ESLint – and why you’d want to
  • The kinds of development-time issues each of those tools catch
  • Using ESLint and TypeScript as documentation sources and to educate developers on best practices
  • Demos of the -often surprisingly intricate- well-crafted static analysis tools can catch in your code

A primary goal of the talk is to get the audience excited about the tooling they can run on their code. This talk will have you detecting bugs, bad practices, and code smells in your web apps at lightning speed! ⚡️

[#B] 書いたJavaScriptがそのままブラウザで動く未来へ (sosuke-suzuki-1) (room: B)

リッチな体験を提供するフロントエンドアプリケーションを構築するとき、どのような技術を使いますか？今日では、Next.js や Nuxt.js や SvelteKit などの数多くの選択肢があります。これらの技術は、開発者体験の向上や、プロダクトのデリバリーの加速、ユーザー体験の改善など、多くのメリットをもたらしてくれます。

このような、いわゆるモダンなフレームワークたちの裏側には、TypeScriptやJSXや独自のテンプレート記法からJavaScriptへと変換を行う機能が隠れています。これらの機能によって、静的型に守られたプログラミングや、直感的なUIの記述が実現されています。

でも、思い出してください。実はJavaScriptは高級なプログラミング言語です。明らかに、人間のための機能がたくさんありますよね？しかし、それでは十分でないから、私たちはJavaScriptをコンパイルターゲットとして扱っているわけです。

では逆に、JavaScript、そしてWebにどのような機能があれば、Webアプリケーション開発者は、JavaScriptを直接書くようになるのでしょうか。

このトークでは、私たちがJavaScriptを直接書かない理由について整理し、現在のWeb標準の動向を踏まえた上で、JavaScriptを直接書く未来について考察します。

  • フレームワーク
    • JavaScriptを直接書かない
    • imo: userscript くらいしか
  • コンパイルターゲットとしてのJSに違和感がある
    • 高級言語なのに

JSのビルドステップ

  • TSからJSへの変換
  • JSXから関数呼び出しへの変換
  • ダウンレベルコンパイル
    • ES2022で追加された機能など
  • モジュールのバンドル
  • minify

どうすればこれらのステップを取り除けるか

  • TS to JS
    • type annotations proposal
    • まだ stage 1
  • JSX → 関数呼び出し
    • ECMAにJSX構文を含めるしかない
    • 議論が行われているが、提案はまだない
      • 懐疑的な人がいて難しそう
  • ダウンレベルコンパイル
    • IEサポート終了
    • 必要性が下がっている
    • eslintで制限の必要はあるかも
  • モジュールのバンドル
    • importに伴うfetchとオーバーヘッド
      • subresource loading with web bundles
      • bundle preloading が希望だったが、、のぞみは薄い
  • minify
    • 汎用的な圧縮技術
    • binary AST
      • しかしその進捗は…

ここまでのまとめ

  • 現代・近未来はできない

私見

  • 書いたJSをそのままブラウザで動かす必要はなくなってきている
    • ビルドステップが複雑
    • 環境が変わってきている
      • vercel とか バイトダンスとか
      • サステナブルになってきている
  • Webのポテンシャルが活かしきれていない感じがしてもったいない

Hono v3 and v4 (yusuke-wada-1) (room: C)

Webフレームワーク「Hono」の v3は今年2月にリリースされ、現在までに新しい機能が導入されています。

型にこだわったValidator、革新的なRPCモード、新しいルーターの追加とプリセット、ホスト名によるルーティングの対応、Server-Timingミドルウェア、Secure Headersミドルウェア、Zodでスキーマを書くOpenAPI拡張、SSRをよりしやすくするc.render()、そして、ストリーミングのためのc.stream()。また、Node.jsアダプタもメジャーリリースとなり、サポートするプラットフォームはAWSも含め10種類以上となりました。

本トークではこれまであまり語られることのなかったHonoの最近のアップデートについて話します。また、次に予定されているv4への展望についても紹介します。

From Loading to Generating: Leveraging AI in State Management (workshop-helpfeel) (room: D)

状態管理における「読み込み中」の表現は、ChatGPTの登場によって「生成中」へとシフトしました。生成的なプロセスを効果的に表現するためには、非同期処理におけるストリームの概念を理解することが重要です。本発表では、言語モデルを含む他の機械学習モデルについて概観し、APIから受け取ったデータのストリームがFetch APIを用いてどのように扱われるかを見ます。最後に、開発者とユーザー双方の視点から、生成AIの力を引き出すユーザーインターフェースの可能性と限界について議論します。

[#C] Unleash Your Product’s Potential: A Beginner’s Guide to Growth Engineering (jon-zhang-1) (room: A)

Join us on an exhilarating journey as we unravel the mysteries of growth engineering and answer burning questions like: “Why does Meta have a whole team dedicated to working on their sign-up flow?” “Does it really matter what color I make this button on my app?” and “What even is growth engineering?”

This talk will demystify the world of growth engineering and uncover the strategies that tech giants like Meta and Google use to grow their user base. We’ll take a closer look at how to use data to drive your decision making and how analytics can be used to fuel your product’s growth.

Prepare to be captivated as we explore the world of growth engineering and reveal the strategies behind attracting hordes of users to tech giants like Meta, Google, and Twitter. We’ll dive deep into the realm of data-driven decision-making and show you how to fuel your product’s growth using the power of analytics. From spotting growth opportunities and optimizing funnels to measuring success with the right metrics, you’ll gain the tools to attract users, improve retention, and boost conversions.

We’ll walk through real-world examples and case studies to show you how to leverage the “understand, identify, execute” framework to run experiments and data loops for continuous improvement. By the end of this talk, you’ll walk away with a clear understanding of growth engineering, (or at least more than before you walked in :) ) armed with practical tips and insights to start your journey towards sustainable product growth.

Whether you’re a beginner scratching their head at everything you just read or a seasoned pro who’s just looking to level up your growth game, this talk will help everyone achieve measurable, impactful growth. Get ready to unleash your product’s potential!

Bunがメジャーリリースされたけど、本当にBunはNode.jsに取って代るほどすごいのか？をAWS Lambdaで検証してみた (masaki-suzuki-1) (room: B)

概要： 今年の9月上旬に、Bunが正式にメジャーリリースされました。 Bunは今までTypeScriptの開発で難解だった点をすべてこれ一つで解決でき、そして何よりNode.jsに比べてとにかく高速であることが売りであり、一部のブログやYouTubeでは「Node.jsの終焉」「Node.jsはオワコン」とまで言われています。

しかし、本当にそうなのでしょうか？

そこで、今回はAWS Lambdaを使用して、実際にWeb APIとしてBunとNode.jsを使用した際の結果を比較し、本当にNode.jsはBunによって終わってしまうのか、BunはNode.jsの代替になるのかをAWS Lambdaの観点で説明したいと思います。

その他、AWS LambdaでBunを使用する方法、およびその際の注意点、そして実際の開発でのユースケースなどを自分が使ってみた経験から説明したいと思います。

[#B] ゲーム「webページ崩し」の仕組み〜あなたの知らないDOMスクリプティングの世界〜 (canalun-1) (room: C)

一昔前の技術だと思われがちなDOMスクリプティング(DOMをブラウザのAPIで直接操作するプログラミング)は、PlaywrightやReactといったモダンなフロントエンドスタックを支える現役の重要な技術です。

本セッションでは、まさにブロック崩しのように、webページ上の要素にボールを当てて消していくゲーム「webページ崩し」([デモ動画](https://x.com/i_am_canalun/status/1707700748610629911))の実装に関する説明を通じて、実践的かつ高度なDOMスクリプティングについて取り扱います。

特に、下記の技術的詳細にスポットライトを当てながら、Playwrightが採用する要素探索の手法や比較的最新のAPIなどなど、奥深くて興味深いDOMスクリプティングの世界にご案内いたします。

  • Shadow DOMやiframeの中にある要素への当たり判定の実装
  • visibilityやopacityだけでは実現できない、「要素がユーザーにとって見えているか」の判定
  • ページレイアウトを極力保ちつつ外側の要素(DOMツリーの親要素)から順に消していく方法

そして何より「DOMってこんなに面白いんだ！」と思って頂ければ、これ以上のことはありません！！

自己紹介

  • tech touch
    • SaaS on SaaS
  • DOMDOM times
  • TAPL.ts

Webページ崩し

  • iframeのMDNのページを消す！
  • 最近はライブラリで隠蔽してるけど、内部はまだDOMいじってる

実装

  • ページを凍結する
    • clearInterval 全て止める
  • すべての要素を取得
  • いくつかの要素はブロックとして扱わない
  • アニメーション、コリジョン、ブロックを消す

各フェーズで考えること

  • 要素を取得
  • 素朴に実装するとshadow dom と iframe をすり抜ける
    • playwright もshadow root 内部で探索してる（？）
    • とれないの
      • cross domain
        • 拡張で postMessage
          • ただ
      • closed shadow root
  • ブロック生成
    • 要素全然消えない
      • div要素wrapとか、見えてないやつとか
      • checkVisibility
  • ブロック除去
    • 一気に消えちゃう
      • ずれる
    • opacityはsubtreeも消えちゃう
    • visibility でその要素だけ消す

ちょっとまてと

  • 複雑すぎないか？
  • DOMはハイレベルなAPIを提供
  • CSS means とかでいろいろ出てくる
  • もうちょっとどうにかできないのか
    • Hixie さん
    • WebGPU baed
      • Google docs は canvas based
    • アクセシビリティは？
      • AOM、新しいAPIでやったらええんちゃう
        • ABI
      • でも検討しててたが、AOMガンガン操作できるとプライバシーの問題が
  • DOMにいろんな責任が押し寄せて世界が広がっていく

[#C] Kotlinで書かれたGraphQLサーバーをNode.jsでモジュラモノリス化している話 (workshop-ubie) (room: D)

ユビーではプロダクトが成長してくなかで技術的負債も溜まってきており、今まさに負債と向き合う時期に差し掛かっています。そのための取り組みとして、技術スタックの統一やモジュラモノリス化などを進めています。今回はその中のひとつとして、Kotlinで書かれているGraphQLのサーバーをNode.jsでモジュラモノリスなシステムに書き直している話しをします。

[#B] Let’s expand reality (vasilika-klimova-1) (room: A)

How long have we been watching movies about reality and how exciting it looks! You may not have noticed, but virtual reality is already in our lives, even our browsers. There are more and more ways to apply these technologies. Let’s look at VR and AR and see how they look in real life. (This talk includes a lot of examples of using 3D in our life and an explanation of how it works using JavaScript)

  • ゲームが好きでプログラマーに
  • three.js

VR

  • 実用例
    • VR chats
    • VR video
    • VR tour
    • training
  • VR actions
    • バーチャルワールド
    • 動き
    • 360土
    • interact
  • probable challenges
    • latency
    • pixel density
    • micro gestures
    • safety & ethics
    • price
    • diziness

AR

  • Pokemon
  • snap inc report
  • 例
    • google meet
    • education、サイズ把握
    • info, 写真じゃなくて大きさわかる
      • ハンバーガー
    • WebShop
  • AR actions
    • 現実ワールドを見る
    • バーチャルワールドのobjectを見る

Web

PrivacySandboxAPIを使ったブラウザ上での広告オークションについて (koji-ota-1) (room: B)

多くのブラウザで廃止されつつある3rd party cookieが担っていたユースケースを実現するためにPrivacySandboxというAPI群が実装されています。中でもweb広告のユースケースを実現するために、webブラウザ上で広告オーディションを実行するProtectedAudienceAPIという仕様があります。ブラウザ上での広告オークションの実行はユーザーのPrivacy情報を漏らさないようにauction workletという特殊な環境で実行されますが、auction workletの制約に加えてユーザーのWeb閲覧を妨げない高速なオークションロジックの実行も求められます。

本発表ではauction workletが持つ制約のポイントや、auction worklet環境下で開発/テストを行い、高速にオークションを実行するための方法について説明いたします。

Visually experience the beauty of mathematics with p5.js (kkeeth-1) (room: C)

There are also many books and videos out there that talk about the fun and beauty of mathematics, but have you ever felt its beauty? In this talk, I would like to approach this beauty visually in the context of art!

[#C] Storybook駆動開発 UI開発の再現性と効率化 (workshop-kaonavi) (room: D)

システム開発には不確実性が多く、顧客への価値の提供やスケジュール管理が難しい。そういった不確実性と対峙するために、アジャイル開発におけるイテレーションのスピードと、顧客が体感できる価値を提供し続けることが重要です。そして、フロントエンド開発を効率的に進めるためには、顧客視点での再現性と集中的な開発環境の構築が必要になってきました。ここでStorybookをインテグレーションテストツールとして活用することで、「Storybook駆動開発」を推進することにしました。このアプローチにより、複雑なフロントエンド開発でも効率的に進め、開発体験を向上させることができた体験をご紹介します。

[#C] React Server Components: The Back-end Killer? (ankur-datta-1) (room: A)

React Server Components have emerged as a game-changing technology, revolutionizing how we build data-driven apps and challenging the traditional role of backend applications.

This talk will explore how React Server Components are transforming the landscape by enabling front-end apps with persistent database connections. We will dive into the power of React Server Components, their seamless integration with back-ends, and the utilization of Prisma ORM to streamline data access.

Join me to discover how this combination of technologies can eliminate the need for traditional back-end architectures, paving the way for a new era of efficient and scalable web development.

Table of Contents:

  1. Introduction
    • Brief overview of React Server Components and their impact on frontend development.
  2. React Server Components: The New Paradigm
    • Deep dive into React Server Components and their ability to handle data-fetching, rendering, and implications for state management on the front-end.
  3. The Back-end Killer: Implications for Backend Applications
    • Examining the impact of React Server Components on traditional backend architectures.
    • Demonstrating advantages such as reduced latency and simplified development workflows.
  4. Understanding Data-Driven Apps as a Frontend Developer
    • Exploring the concept of data-driven apps and their requirements for persistent database connections.
    • Challenges for frontend devs in the data layer
      • Relational vs object-oriented
      • Persistence
      • Data modeling
  5. Streamlining Data Access with Prisma ORM
    • Introducing Prisma ORM as a powerful tool for efficient data access and manipulation.
    • Exploring its integration with React Server Components for seamless database connections.
  6. Real-World Examples and Case Studies
    • Showcasing organizations that have embraced React Server Components, highlighting their benefits and success stories.
  7. Further Considerations
    • Discussing potential challenges and considerations when adopting React Server Components; use cases not being covered by RSCs
  8. Conclusion
    • Recap of key points and takeaways from the talk.

Intlの今までとこれから (ryusei-sajiki-1) (room: B)

JavaScriptの国際化APIとして標準化されているIntlは近年多くのブラウザで基本的な機能がサポートされるようになりました。また新しい機能や既存の機能を拡張するプロポーザルも提出され積極的に議論されており、今後一層便利になる ことが予想されます。

今回のセッションではこのようなIntlの仕様策定のあゆみを振り返るとともに、現在提案されているProposalや議論からIntlのこれからについて話します。このセッションを通じてIntlが解決してきた課題はなんなのか、Intlが今後どのように進化するのかを包括的に理解しましょう。

具体的に以下のような内容を盛り込む予定です。

  • Intlの最初の仕様書が2012年に公開されて以降、現在までの仕様の変遷とそれらの仕様が解決したかった課題について見ていきます。
  • Intlに関連する周辺仕様、特にUnicodeとの関係性などを解説します。
  • Intlで近年追加されたProposalや今後追加される予定のProposalについて解説し、今後Intlがどのように便利になるのか具体例とともに紹介します。

[#C] Practical guide to building accessible forms in React (kateryna-porshnieva-1) (room: C)

Web forms are crucial for user interaction on the web, and to ensure our products provide an inclusive experience for all, we need to build them with accessibility in mind. In this talk, we’ll dive into best practices and practical tips for crafting accessible forms that won’t leave anyone behind

We’ll start by diving into what accessibility is and how assistive technology works on the web. With this foundation, we’ll go through common patterns in forms and how to implement them accessibly. We’ll talk about: labelling, providing instructions, errors and validation, testing, managing focus, and more – all backed by practical examples.

[#B] デザインシステム仕切り直し（仮） (workshop-wantedly) (room: D)

デザインシステムを継続的に改善していくための組織を立ち上げた背景や経緯などをお話します。

  • 共通の考え方
    • Surface
      • 4つのfoundmationを
    • Touch Area
      • まーじんではなくてタッチエリアがあるんだよ
  • デザイナーがUIデザインするのと同じ考え方で実装する
  • なぜUIデザインシステムを作るのか
  • 振る舞いの一貫性
  • ベーシックなユーザビリティの担保
  • デザインアウトプットの効率化

デザインシステムこれまで

  • 2018 コンポーネントセットのデザインが誕生
    • React実装が誕生、プロダクションコードに使われていない
  • 2019 DS を使ったプロダクト開発がスタート
  • 裏側で2回失敗
    • v1 ナイーブな実装
      • surface, touch area の概念がない
    • v2 コンポーネントセットを作ったデザイナーとチャレンジ
      • 失敗例：ミスを誘発するAPI
        • セマンティクス一致しない
    • v3
      • ライブラリへの依存を減らす
      • Surface を簡単に作れるように
      • HTML要素を分離

学んだこと

  • デザイナーの思想をしっかり掴む必要がある
    • Figmaを実現するだけではない
  • どうすればよかったか
    • キックオフを実施、共通認識をもつべきだった

これから

  • デザインシステムギルド
  • ギルドはウォンテッドリーで採用されている組織モデルのいち体系
  • 発足のきっかけ
    • 局所的・散発的に議論が行われ、結論のまとまりがない
    • 実装者の大半が退職
    • それぞれがプラットフォーム向け実装を開発していた
      • ギルドで共通の考え方
  • Design System Guild を立ち上げました | Wantedly, Inc.

スポンサートーク

Wantedly

Chatwork

  • GraphQL化
    • rpc風APIを使うのが年々苦しい
    • フィーチャーチームを目指す
  • TS+JS
    • 18万行
  • コンポーネント毎にAPI切り替え
  • relay つかって一度にリクエストしてくれる

PLAID

  • とささん
  • めちゃハキハキしゃべって良い
  • KARTE
    • ユーザーの行動、解析
    • 秒 13万件
    • 裏側の基盤
  • svelte
    • パーソナライズされていた web popup
    • 軽い

カオナビ

  • 新卒
  • アンケートツールを開発、OJT
  • 失敗ナレッジを残す

Forkwell

  • しもおか
  • カジュアルにスキルを把握
  • アウトプットの連携

Tokyo Dev

  • 英語が喋れるけど、あまり日本語しゃべれないひとむけ
  • https://www.tokyodev.com/
  • Ruby Kaigi
    • 壁があるのもったいない
  • ブログを書いて発信してた
    • もっと質問きて、ブログ書いて
  • 求人情報

HireRo

  • エンジニアを採用する側のサービス
  • コーディングテスト
  • キーストロークを再現

ドワンゴ

  • 教育事業
  • べるりしあ
  • 個人CFPはおちた
    • Call for Papers
  • N予備校
  • Nest

Helpfeel

  • pastak
  • 環境良さそう
  • tokyoto.js

Auth0 by okta

  • 認証認可
  • demo
  • required auth

Second System Syndrome - the tale of power-assert (takuto-wada-1) (room: A)

自作 OSS プロダクト、特に power-assert の開発において典型的な「セカンドシステムシンドローム」に罹患しました。「セカンドシステムシンドローム」とは何か、どうやってそこからリカバリーするか、自分の体験をベースに説明します。あわせて、当日新しいバージョンをリリースする予定です。

  • 改行されてたとき
  • JSX
    • わちゃわちゃ
    • トークンを渡す
  • 文字列の幅
    • 全角文字列ずれる
  • ルールズオブプログラミング
  • 簡単な前提を置く
  • 孫子の兵法
    • 衢地（くち）
    • 抑えておくといい場所
    • FE 今は Rust だろう
      • コンセプトから学んでいくのが良い
  • Available now
    • Rust

Hope is postponed disappointment (luca-mugnaini-1) (room: A)

The solution for the exception problem is not having exceptions. Throwing exceptions and hoping that someone will take care of them may lead to disappointment. A sound type system can help us build resilient web applications. In Rakuten, we use Elm to prevent runtime exceptions in the authentication system used by millions of users every day. A similar technique can be implemented in TypeScript too.

  • rakuten
  • undefined
  • try-catch
  • 鉄道での比喩
    • 関数はrailみたいなの
    • throw すると railから外れる
  • Result type でやろうず
    • Error の rail に移る
  • Elm pattern matching
  • Result型
  • map と andThen
  • TS だと 逆順に書かないといけない
    • pipe operator, parial application でかけるが、stage2, stage1

The Past and Future of Kuma UI (poteboy-1) (room: A)

I’m the creator of Kuma UI, a Japanese OSS that gained attention as one of the few CSS-in-JS libraries compatible with React Server Components. Discover the journey of how someone with no prior OSS experience built this zero-runtime UI component library, the story behind its creation, its evolution, and the future vision for Kuma UI.

  • kumaUIの作者
  • https://www.kuma-ui.com/
  • utility first な CSS in JS
  • 7月に延びていま1000star
  • RSC互換
  • 2つの困難
    • 技術的問題
      • コアメンバーに強い人が来た
    • 認知度の問題
      • 海外をターゲットに伸ばすには
      • いろいろ書き込んでみたが、全然伸びない
      • Panda CSSの登場
      • かちぐまにしたい
  • v1.0
    • 目玉機能 hybrid in css in js

JavaScript なしで動作するモダンなコードの書き方 (azukiazusa-1) (room: A)

Next.js、Remix、SvelteKit といった近年のフレームワークは、JavaScript がなくても動作することを一つの価値として提供しています。

例えばSvelteKit のフォームではプログレッシブエンハンスメントとして、JavaScript が利用できる環境ではリッチなユーザー体験を提供しつつ、JavaScript が使えない環境においては HTML のフォームとして振る舞うことでアプリケーションの機能を変わらず提供できます。 React Server Component はサーバー側で HTML に変換されるため、クライアントに JavaScript のコードが配信されることはありません。React Server Component では `useState()` を使用できないといった制約がありますので、我々開発者は React Server Component の利点を十分に発揮するために、JavaScript を用いた状態管理を行う範囲を狭めることが求められています。

このトークでは、CSS の :has() セレクターや、Popover API といった、従来は JavaScript を用いなければ提供できなかった機能を代替する方法を紹介します。

https://speakerdeck.com/azukiazusa1/javascript-nasidedong-zuo-surumodannakodonoshu-kifang

  • プログレッシングエンハンスメント
  • ハイドレーション前に操作できる
    • FID/INPに有利
  • Server Components がデフォルトというメンタルモデル
  • JSで実現していた機能をHTML/CSSに移す
  • :user-invalid 擬似クラス
  • popover
  • selectlist
  • invokers

画面遷移のアクセシビリティ課題を解決しうる Navigation API への期待 (yamanoku-1) (room: A)

クライアントサイドルーティングにおける画面遷移したことを支援技術に伝えるために JS と WAI-ARIA を使用した Route Announcer という手法があります。これにより画面が変わったことを通知できますがそれ以外にも画面遷移で考慮しなければならないアクセシビリティの課題があります。それらの課題の紹介と Navigation API によってそれらが解消できそうな期待を仕様に沿って紹介します。

  • やまのく
  • クラウドワークス
  • 画面遷移の歴史
    • MPA
    • Ajax
    • Pjax
    • History API
    • SPA
  • view transition API
  • SPAアクセシビリティ課題
    • 画面遷移しているように見せかけている
  • Route Announcer
    • WAI-ARIA と　JSをあわせて支援技術に通知
    • 各種FEでも対応
  • CSだけの操作における弊害
    • 画面遷移の完了がブラウザ側で検知できていない
    • フォーカスマネジメント
    • スクロール位置
  • Navigations API
    • 新たなAPI
      • 現在Living Standardに仕様が載っている
    • 実際のコードで上記問題を解決

Scraping

{
  const res = await fetch(
    'https://jsconf.jp/2023/page-data/sq/d/3084875834.json',
    {
      headers: {
        'sec-ch-ua':
          '"Chromium";v="118", "Google Chrome";v="118", "Not=A?Brand";v="99"',
        'sec-ch-ua-mobile': '?0',
        'sec-ch-ua-platform': '"macOS"',
      },
      referrer: 'https://jsconf.jp/2023/schedule/',
      referrerPolicy: 'strict-origin-when-cross-origin',
      body: null,
      method: 'GET',
      mode: 'cors',
      credentials: 'omit',
    },
  )
  const data = await res.json()
  console.log(data)
  const talks = data.data.allTalksYaml.edges
  const talkUrls = talks
    .sort(({ node: { room: a } }, { node: { room: b } }) => {
      return a.localeCompare(b)
    })
    .sort(({ node: { startsAt: a } }, { node: { startsAt: b } }) => {
      return a.localeCompare(b)
    })
    .map(
      ({
        node: { uuid, title, titleJa, description, descriptionJa, room },
      }) => {
        if (uuid.includes('day1-break')) return null
        return `** [[https://jsconf.jp/2023/talk/${uuid}/][${
          titleJa || title
        }]] (${uuid}) (room: ${room})
${(descriptionJa || description).replaceAll('* ', '- ')}
`
        // [[https://jsconf.jp/2023/talk/anirudh-sharma-1/][Web Internals: Mastering the JavaScript Engine - Anirudh Sharma | JSConf JP]]
      },
    )
    .filter(Boolean)
    .join('\n')
  console.log(talkUrls)
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment