Electron
イベント
該当するコンテンツが見つかりませんでした
マガジン
該当するコンテンツが見つかりませんでした
技術ブログ
はじめに # Deno 2.9 リリースおめでとうございます。 Deno 2.9 | Deno Electron 大好きな自分としても気になるのはやはり Deno Desktop です。 Tauri と同様 WebView をバックエンドにする構成と Electron と同様 Chromium ベースの構成を選べるとのことで、これは試すしかないと思いました。 公式ドキュメントは以下にあります。 https://docs.deno.com/runtime/desktop/ --> Caution Deno ブログには以下のように書かれており、2.9 時点ではデスクトップ機能は実験的段階です。 deno desktop is experimental in 2.9. The surface described here is stabilizing and some platform features are still landing. 使ってみる # まずは 2.9 にアップグレードしておきます [1] 。 deno upgrade main.ts に Deno.serve を使って普通にサーバープログラムを書きます。 main.ts Deno.serve(() => new Response( "<!DOCTYPE html><h1>Hello from Deno desktop </h1>", { headers: { "content-type": "text/html" } }, ) ); 同じディレクトリで deno desktop main.ts を実行します。 $ deno desktop main.ts ⚠ deno desktop is experimental and subject to change Check main.ts Compile main.ts to hello.dylib Embedded Files hello.dylib └── main.ts (430B) Files: 1.91KB Metadata: 1.38KB Remote modules: 12B Downloading laufey webview backend for aarch64-apple-darwin (v0.4.0) Download laufey-webview-aarch64-apple-darwin.tar.gz 97.44KiB/97.44KiB Codesigning bundle with identity "-" hello.app/Contents/MacOS/laufey_webview: replacing existing signature hello.app/Contents/MacOS/hello.dylib: replacing existing signature Bundle hello.app 最後の出力で、ルートに hello.app (macOS のアプリ実行ファイル)が生成されており、起動できます（Windows の場合は、hello.exe が生成されます）。 Deno のコンセプト通り、追加のモジュールや設定なし(Out of the box)でデスクトップアプリが生成されました。 Deno Desktop の開発体験 # HMR (Hot Module Replacement) オプション付きで起動することで、ローカルの開発サーバを立ち上げ、コード変更を検知してアプリ内容を即時更新してくれます。 deno desktop --hmr main.ts ⚠ deno desktop is experimental and subject to change Compile main.ts to file:///Users/kondoumh/Library/Caches/deno/desktop/5f4a00908e99d886/hello.dylib Embedded Files hello.dylib └── main.ts (422B) Files: 1.9KB Metadata: 1.38KB Remote modules: 12B Running desktop app with HMR (watching /Users/kondoumh/dev/deno-study/desktop/hello) Runtime loaded successfully from: /Users/kondoumh/Library/Caches/deno/desktop/5f4a00908e99d886/hello.dylib Runtime started [desktop] dylib path: "/Users/kondoumh/Library/Caches/deno/desktop/5f4a00908e99d886/hello.dylib" Listening on http://127.0.0.1:52958/ main.ts のコードを書き換えると、保存後すぐに画面へ反映されます。 --> Information Electron では HMR は標準では利用できず、別途 Forge などで開発サーバーを起動する必要があります。 https://developer.mamezou-tech.com/blogs/2024/01/29/electron-forge-introduction/ UI の ローカル HTTP サービスによる実現 # Electron (Forge など) ではローカルサーバーの利用は開発時が中心で、配布後は file:// でアセットを読む構成が一般的です。 これに対し Deno Desktop は、配布後のバイナリでもローカル HTTP サーバーを内部起動し、空きポートを自動割り当てして UI を描画します。サーバーはプロセス内で閉じており、外部公開はされません。ポート衝突を意識せずに済むのも良い点です。 この「開発時もビルド済みバイナリでも、同じ HTTP 実行モデルで UI を提供する」設計により、 開発時とデプロイ時の挙動に差がない コンテンツはブラウザとデスクトップで同じ動きをする Next.js などのフレームワークがそのままデスクトップアプリの中で動く といったメリットが得られます。 https://docs.deno.com/runtime/desktop/serving/ DevTools の起動 # Electron や Tauri と同様、DevTools によるデバッグが可能です。BrowserWindow を起動し、 openDevtools メソッドを呼ぶだけです。 const win = new Deno.BrowserWindow({ title: "My Deno Desktop App", width: 800, height: 600, }); win.openDevtools(); https://docs.deno.com/runtime/desktop/devtools/ --> Information いまのところ、DevTools のフルサポートはバックエンドを cef にしている時のみです。 以下のように、指定して起動する必要があります。 deno desktop --hmr --backend=cef main.ts バックエンドとフロントエンドの通信(Bindings) # Electron の IPC 通信は render.js と main.js を preload.js 経由でブリッジする必要があり、かなり面倒です。Deno デスクトップでは BrowserWindow にバインドした関数を bindings というグローバルオブジェクトにより簡単に呼び出すことができます。 Deno ランタイムとレンダリングバックエンドはスレッドやプロセスとして動作し、呼び出しはプロセス内チャネルを介して行われます。このサンプル構成ではソケットベースの IPC を直接扱わずに済むため、Electron の ipcMain / ipcRenderer、Tauri の invoke と比べて見通しよく書けるのが利点です。 実際のコードで見てみましょう。 const win = new Deno.BrowserWindow({ title: "Bindingsのテスト", width: 800, height: 600, }); // ========================================== // 1. バックエンド側：フロントから呼ばれる関数を登録 // ========================================== win.bind("getSystemInfo", async (userName) => { console.log(`[Deno側] フロントエンドから呼ばれました！ 引数: ${userName}`); // Denoの機能を使ってOSの情報を取得 const denoVersion = Deno.version.deno; const os = Deno.build.os; // 少し重い処理をシミュレート（0.5秒待つ） await new Promise(resolve => setTimeout(resolve, 500)); // フロントエンドに返すデータ（JSON化できるものなら何でもOK） return { message: `こんにちは、${userName}さん！`, os: os, denoVersion: denoVersion }; }); // ========================================== // 2. フロントエンド側：画面のHTMLを返す // ========================================== Deno.serve(() => { const html = ` <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>Bindings Test</title> </head> <body> <h1>Deno Desktop Bindings</h1> <button id="btn">システム情報を取得</button> <pre id="result">ここに結果が出ます</pre> <script> // ボタンが押された時の処理 document.querySelector('#btn').addEventListener('click', async () => { const resultArea = document.getElementById('result'); resultArea.textContent = "取得中..."; try { // 💡 bindings を使ってバックエンドの関数を呼び出す const data = await bindings.getSystemInfo("kondoumh"); // 結果を画面に表示 resultArea.textContent = JSON.stringify(data, null, 2); } catch (error) { resultArea.textContent = "error: " + error.message; } }); </script> </body> </html> `; return new Response(html, { headers: { "content-type": "text/html" }, }); }); アプリ画面です。 システム情報を取得 ボタンをクリックするとしばらく呼び出し中になり、結果が表示されます。 結果が表示された状態。 アプリを起動しているバックエンドでは次のようにログが出ています。 [Deno側] フロントエンドから呼ばれました！ 引数: kondoumh すごくシンプルです。OS のネイティブ機能と Web UI を簡単に連携できるのがいいですね。 https://docs.deno.com/runtime/desktop/bindings/ メニュー の利用 # アプリケーションメニューの実装。 BrowserWindow の setApplicationMenu メソッド内でメニューオブジェクトを定義して渡します。 BrowserWindow にイベントリスナーを登録してメニューがクリックされた時の振る舞いを実装します。 role などは Electron と同じですね。 win.setApplicationMenu([ { submenu: { label: "File", items: [ { item: { label: "New", id: "new", accelerator: "CmdOrCtrl+N", enabled: true, }, }, { item: { label: "Open…", id: "open", accelerator: "CmdOrCtrl+O", enabled: true, }, }, "separator", { item: { label: "Save", id: "save", accelerator: "CmdOrCtrl+S", enabled: true, }, }, { role: { role: "quit" } }, ], }, }, { submenu: { label: "Edit", items: [ { role: { role: "undo" } }, { role: { role: "redo" } }, "separator", { role: { role: "cut" } }, { role: { role: "copy" } }, { role: { role: "paste" } }, ], }, }, ]); win.addEventListener("menuclick", (e) => { const detail = (e as CustomEvent).detail; switch (detail.id) { case "new": console.log("New clicked"); break; case "open": console.log("Open clicked"); break; case "save": console.log("Save clicked"); break; } }); コンテキストメニューの実装。 Deno.MenuItem の配列を作成して、BrowserWindow の showContextMenu に座標とともに渡します。 const contextMenu: Deno.MenuItem[] = [ { item: { label: "Copy", id: "copy", enabled: true } }, { item: { label: "Paste", id: "paste", enabled: true } }, "separator", { item: { label: "Properties…", id: "props", enabled: true } }, ]; // Trigger from a right-click. The webview may not forward the browser // `contextmenu` event, so handle the secondary mouse button on the window. win.addEventListener("mousedown", (e) => { if (e.button === 2) { win.showContextMenu(e.clientX, e.clientY, contextMenu); } }); win.addEventListener("contextmenuclick", (e) => { if (e.detail.id === "copy") { console.log("Copy clicked"); } if (e.detail.id === "paste") { console.log("Paste clicked"); } if (e.detail.id === "props") { console.log("Properties clicked"); } }); --> Information ここではメニューのクリックイベントでログを出力していますが、ログ自体はアプリを起動しているターミナル側に出ますのでご注意ください。 https://docs.deno.com/runtime/desktop/menus/ フレームワークを利用した開発 # Deno.serve() を利用したサンプルを見てきましたが、Deno デスクトップでは、以下のフレームワークとともに利用可能です。これらのプロジェクトのディレクトリで deno desktop を起動すると、フレームワークを自動検出してアプリを構成します。多くのモダンフレームワークがサポートされています。 Next.js Astro Fresh Remix Nuxt SvelteKit SolidStart TanStack Start Vite ローカルで動いてるのに SSR を使うというのがなんとも不思議な感じですが、ちゃんと動いてセキュアであればヨシ！という感じでしょうか。 https://docs.deno.com/examples/next_tutorial/ Next.js のアプリを作成します。 deno run -A npm:create-next-app@latest 作成したプロジェクトディレクトリへ移動して実行します。 cd <project-dir> deno desktop -A Next.js のアプリが、外部サーバーなしでまるっとデスクトップ内で動いてるのは不思議な感じです。 https://docs.deno.com/runtime/desktop/frameworks/ バックエンドの選択について # デスクトップアプリは配布するバイナリのサイズも重要です。小さいに越したことはありません。 Electron は Chromium を内包するため、インストールされたバイナリサイズは300MBぐらいの大きさになったりします。 Deno Desktop の場合、OS にプリインストールされている WebView を使えば70MB程度です。CEF(Chromium) だとやはり300MB程度になります。 OS 依存の WebView だと、Windows と Mac で微妙に CSS や JS の挙動が変わるクロスブラウザ問題が発生するため、そのための対応やテストも必要になります。機能が少ないうちは WebView でもいいかもしれませんが、機能が増えてくるとテストの手間も何倍にもなっていきます。 Deno Desktop の場合、最初は軽量な WebView でスタートし、クロスブラウザが重荷になってきたら、ちょっと配布サイズは大きくなるけど、CEF にスイッチできるのがいいかなと思います。 https://docs.deno.com/runtime/desktop/backends/ --> Information Tauri だとこの辺、Servo ベースの自前 WebView プロジェクト Verso 待ちですが、Deno は既存の Chromium を選択可能にしているあたり、現時点での割り切りが感じられますね。 Electron との比較 # 既存 Web アプリをデスクトップ化したいユースケースでは、Deno Desktop はかなり有力です。 一方で、Electron の WebContentsView のような高度なマルチビュー構成を前提にしている場合は、現時点では Electron のほうが適しています。たとえば VS Code や Figma のように、複数ビューを細かく制御するタイプのアプリです。 ざっくり整理すると次のような感触です。 単一ウィンドウ中心 + 既存 Web 資産活用: Deno Desktop はかなり良い 複雑なウィンドウ/ビュー管理: Electron が依然強い --> Information マルチビュー構成の対応の弱さは Tauri も同様です。 https://developer.mamezou-tech.com/blogs/2025/12/01/porting-an-electron-app-to-tauri2/ Electron の WebContensView 構成については以下の記事をご参照ください。 /blogs/2024/08/28/electron-webcontentsview-app-structure/ https://docs.deno.com/runtime/desktop/comparison/ さいごに # 以上、Deno Desktop 機能を一通り試しました。 Out of the box でここまでデスクトップ開発体験が整っているのは率直に驚きです。タスクトレイやメニュー、Bindings など、アプリらしさを出すための API が最初から揃っているのも好印象でした。 Tauri と違ってアプリ側をすべて TypeScript で書けるため、既存 Web アプリをベースに「メニューやタスクトレイを追加し、OS 機能と連携する」用途ではかなり相性がよいと感じます。最小構成なら、デスクトップアプリ化自体は1時間もかからないはずです。 --> Information Tauri も JS の API を生やして、Rust 知らない勢を取り込もうとしてはいます。 Deno のキラー機能になる可能性もありますね。experimental から安定版へ向けて、今後の熟成がとても楽しみな機能です。 2026年7月6日現在の最新は 2.9.1 です。 ↩︎
はじめに 私が開発ツールに求めることをZedは満たしていた すぐに開けること コードが追いやすいこと 複数画面を上下左右に開けること ディレクトリがツリーで開けること Git関連機能にアクセスしやすいこと VSCode、Ghostty、Zedを比較する Zedの使用感 Zedの微妙なところ ACP経由のエージェント体験はCLIより遅く感じる ファイルパスクリックで開けない VSCode拡張に依存している人は移行しづらい まとめ はじめに 4月にラクスに入社しました。kazuki kanekoです。 研修を受けつつ、開発環境を立ち上げようとVSCodeをセットアップしていました。 すると、AIエージェント開発課のメンバーから「Zedいいですよ」とおすすめしていただきました。 これが、私がZedを知ったきっかけでした。 今は紆余曲折ありながら、Zedに落ち着いています。 以前はVSCodeを中心に使っていて、困っていたわけではありませんでした。 ただ、Zedを使い始めてから、 「VSCodeの動作って、実はけっこう重かったんだな」 ということに気がつきました。 また、Ghosttyについてもおすすめしていただいていたので、一時期はZedとGhosttyを同時に使っていました。 ただ、今は割とZedだけで完結している状態になってきています。 そこで今回は、VSCode、Ghostty、Zedを使ってきたうえで、なぜ今Zedに落ち着いているのかを書いていきます。 まず、前提としてZedについて整理します。 Zedとは、高速性、コラボレーション、AIとの連携を重視して作られているコードエディタです。 公式サイトでは、Zedは「speed」と「humans and AIとの collaboration」のために作られたミニマルなコードエディタとして説明されています。 macOS、Linux、Windowsで利用でき、Rustで一から書かれていて、複数CPUコアやGPUを活用する設計になっています。 Zedを作っているのは、AtomやTree-sitterに関わってきたチームです。 AtomやElectron、Tree-sitterなどの開発経験の延長線上にあるプロダクトとして、Zedが作られています。 Zedの特徴は、単に「軽いエディタ」というだけではありません。 Rust製で、独自UIフレームワークであるGPUIを使い、GPUを活用するような設計になっています。 Zed 1.0の記事では、AtomのようにWeb技術の上に作るのではなく、GPU上のshaderにデータを渡すような、いわばゲームのような作り方を選んだと説明されています。 ソース： https://zed.dev/ つまりZedは、VSCodeのようなGUIエディタの便利さを持ちつつ、より軽く、より高速に動くことをかなり強く意識して作られたエディタだよ、という感じです。 私が開発ツールに求めることをZedは満たしていた 私が開発ツールに求めるのは、以下の５つ すぐに開けること コードが追いやすいこと 複数画面を上下左右に開けること ディレクトリがツリーで開けること Git関連機能にアクセスしやすいこと 順に説明します。 すぐに開けること まず、すぐに開けることです。 GitHubを見ていて、 「このファイル、エディタでちゃんと見たいな」 と思うことがあります。 そういう時にVSCodeで開くと、体感で5秒から6秒くらいかかることがありました。 もちろん数秒なので、めちゃくちゃ遅いというほどではありません。 ただ、開発中の「ちょっと見たい」場面では、この数秒が地味に気になります。 メモ帳みたいにパッと開いて、すぐ見られたらいいのになと思っていました。 Zedはこの「パッと開ける感じ」がかなり良いです。 エディタを開くまでの心理的な重さが少なくて、ちょっと確認したいときにも気軽に開けます。 この軽さは、毎日使っているとかなり効いてきます。 コードが追いやすいこと 次に、コードが追いやすいことです。 コードを読んでいる時には、いろいろな情報を行き来します。 たとえば、 関数の定義元に移動する 型定義を見る クラスやinterfaceの中身を見る 呼び出し元を確認する ファイルをまたいで処理の流れを追う といったことをよくやります。 このときに、定義元にすぐ移動できたり、型ヒントが見られたり、クラス名などにカーソルを当てたときに関連箇所が薄くマーカーされて見やすかったりすると、かなり助かります。 Zedは、このようなIDEの機能を提供してくれています。VSCodeほど充実してませんが、Ghosttyよりは充実しています。 複数画面を上下左右に開けること 複数画面を上下左右に開けることも重要です。 Ghosttyのようなターミナルは、分割の体験がかなり良いです。 上下左右に画面分割できるので、横3、縦2の6画面みたいな形でも開発できます。 Zedでもエディタを上下左右に分割できます。 そのため、Ghosttyのような画面分割の気持ちよさをZedは提供してくれています。 ディレクトリがツリーで開けること ディレクトリをツリーで開けることも大事です。 私は、ディレクトリ構造を見ながら開発したい派です。 たとえば、 controller service repository domain schema migration test のような構成を見るだけでも、そのプロジェクトがどういう責務分割をしているのかがわかるので、どこを変更すればいいのかなどがわかりやすいです。 ZedにはProject Panelがあり、ディレクトリツリーを見ながら開発できます。 Git関連機能にアクセスしやすいこと Git関連機能にアクセスしやすいことも、自分にとってはかなり重要です。 正直、毎回ターミナルで git status を打ったり、commitをコマンドでやったりするのは少しめんどくさいです。 もちろんCLIでやった方が速い場面もあります。 ただ、変更ファイルを一覧で見たり、diffを確認したり、stageする変更を選んだりする作業は、GUIで見たいことが多いです。 VSCodeのGit Graphみたいな感じで、ブランチや履歴を見たり、変更内容を確認したりできるとかなり楽です。 ZedにはGit PanelやProject Diffがあり、変更ファイルを確認したり、diffを見たり、stage / unstageしたりできます。 日常的なGit操作であれば、かなりZed上で確認できます。 VSCode、Ghostty、Zedを比較する ここで、VSCode、Ghostty、Zedを比較してみます。 ただし、Ghosttyはエディタではなくターミナルエミュレータです。 なので、厳密にはVSCodeやZedと同じ種類のツールではありません。 ここでは、以下の3つの開発スタイルとして比較します。 VSCodeのような全部入りGUIエディタ GhosttyでCLIツールを組み合わせてエディタっぽく使うスタイル Zedのような軽量GUIエディタ 観点 VSCode Ghostty Zed 起動の軽さ 重く感じることがある 軽い 軽い コードジャンプ 強い 工夫が必要 強い ファイルツリー ある 工夫が必要 ある 画面分割 できる かなり強い 強い Git UI かなり強い 工夫が必要 強い AIエージェント 拡張＋CLIエージェント CLIエージェント前提 ACP＋CLIエージェント 自分の印象 全部入りだけど、不要な機能も多く重い 軽いが、使いこなすのに工夫が必要 軽さと機能のバランスが良い VSCodeでも普通に困らないなと思います。 拡張機能も豊富で、Gitも見やすく、デバッグやリモート開発なども含めると、かなり全部入りの開発環境です。 なので、VSCodeが悪いという話ではありません。 ただ、自分の使い方では、少し重く感じる場面がありました。 Ghostty中心のCLI開発は、軽さと自由度がかなり良いです。 ターミナル分割もしやすく、AIエージェントとの相性が一番いいと思いました。 AIエージェントが作業完了すると通知が飛ぶのがいいですね。 ただ、私の場合は、コードを追うときに 定義ジャンプ、ファイルツリー、Git diffなどを自然に見たい場面が多かったです。 比較すると個人的にはZedは、そのVSCodeとGhosttyの中間かなと思っています。 Zedの使用感 ここからは、実際にZedの画面を開きながら、使用感を共有できればと思います。 Zedを立ち上げると以下のような画面が開きます。 初めは何にもないです。VSCodeは初回から何やらたくさん出てきますよね。 何も無さすぎて、初めは戸惑うのですが、 画面底の帯部分（赤で囲った部分）に配置されているアイコンをクリックすると、ターミナルだったり、ファイルツリーを開くことができます。 VSCodeっぽく使いたい場合は、 ファイル、git関連機能、ターミナル、Copilotみたいな感じで開くとそれっぽく使えます。 やろうと思えば、Ghostty風の配置もできます。 Zedでこの配置をするメリットはあまりないので、それならGhosttyがいいかなとか思いますが、一応できます。 私の配置は以下の様な感じです。 エージェントを並列で使いたいので、ターミナルを3枚、git関連情報を右側で見ながら、ファイルも開きながらという感じで開発しています。 ブログ形式でZedの使用感を伝えるのは、難しいなと思いつつ、画面構成の自由度の高さだったり、Copilot、ファイルツリー、git関連機能など、ほしい機能は最初から入っていて、使いやすそうだなというのが伝われば幸いです！ 画像では伝わらないですが、今の画面構成を変更したりする操作がサックサクで動く感じです。 Zedの微妙なところ ここまでZedの良いところを書いてきましたが、もちろん完璧ではありません。 特に、AIエージェントまわりはまだ、CopilotやCLIがいいなと感じることはあります。 ACP経由のエージェント体験はCLIより遅く感じる ZedはACP経由で外部エージェントと連携できます。 これは組み込みのAIエージェント機能に依存しないという点で便利なのですが、自分の体感では、ACP経由のエージェント体験はCLIより少し遅く感じることがあります。 CLIでエージェントを使っていると、入力してすぐ反応が返ってくる感じがあります。 一方で、ZedのACP経由だと、UIを挟むぶんレスポンスの出方が少し遅く感じることがあります。 これは設計上ある程度仕方ないのかもしれません。 ただ、CLIの即応感に慣れていると、ここは少し気になります。 ファイルパスクリックで開けない AIエージェントが生成した文章の中に、 src/foo/bar.ts のようなファイルパスが含まれることがあります。 このとき、そのファイルパスをクリックしてそのままファイルを開けると便利です。 VSCodeだと、このあたりの導線が自然に感じることがあります。 一方で、Zedでは、AIエージェント出力内のファイルパスは、ファイルパスのリンクになっていないので、ただの文字列です。 VSCode拡張に依存している人は移行しづらい これはZedというより、VSCodeから別エディタへ移るとき全般の話でもあります。 VSCodeは拡張機能がかなり強いです。 たとえば、 Git関連 Docker Dev Containers Remote SSH デバッグ 各種言語サポート GitLens Copilot など、エディタというより開発プラットフォームに近いです。 なので、VSCode拡張に強く依存している人が、いきなりZedへ全部移行するのは難しいと思います。 私の場合は、VSCodeのすべてが必要だったわけではありません。 だからZedのバランスが合っていました。 まとめ Zedは完璧なエディタではありません。 VSCodeほど何でも揃っているわけではありません。 GhosttyほどCLI開発体験が良いわけではありません。 ただ、色々なバランスを考えると今の私にはZedがかなり合っているという結論になりました。 軽く開ける。 コードを追いやすい。 ファイルツリーがある。 画面分割できる。 Git機能にアクセスしやすい VSCodeに慣れているが、でも、もう少し軽く使いたいという方 Ghosttyの軽さが好きだが、手軽にコードジャンプやGit UIが使いたい方 Zedいいですよ。
こんにちは！ファインディの大石（ @bicstone ）、甲斐（ @karukan013L23 ）、千田（ @_c0909 ）です。先日、ファインディはベルサール羽田空港で開催された「TSKaigi 2026」に協賛しました。 今回はDevRelメンバーとフロントエンドエンジニア3名で参加し、ブース運営を行いました。本記事ではTSKaigi 2026において印象深かったセッションの紹介や登壇、ブース出展などの活動内容を紹介します。 ブースで実施したユーティリティ型アンケートの集計結果（480票）も後半で公開していますので、ぜひ最後までお読みください。 TSKaigi 2026について 印象深かったセッション 【大石】TS 7: How We Got There 【甲斐】tscからtsgoへ ── DenoのTypeScript基盤はどう変わったか 【千田】Oxlint は ESLint / typescript-eslint を置き換えられるか？ 【大石】CfP登壇: TypeScript 6.0での型推論修正を追う ファインディの活動 アンケート結果 さいごに お知らせ TSKaigi 2026について TSKaigiは日本最大級のTypeScriptをテーマとした技術カンファレンスです。東京都大田区のベルサール羽田空港にて、2026年5月22日(金)〜23日(土)に開催されました。 2026.tskaigi.org 印象深かったセッション 興味深いセッションが多くありましたが、その中でも3名それぞれが印象に残ったセッションを紹介します。 【大石】TS 7: How We Got There 2026.tskaigi.org TypeScriptチームのJake Baileyさんによる、TypeScript 7をGo言語へ移植した経緯と成果についての基調講演です。 特に印象的だったのは、Goを採用した理由を体系的に知ることができた点です。 JavaScriptではスレッド間でオブジェクトを共有できず、async/awaitが関数全体に伝播してしまうため、並列化が困難でした。 Goのgoroutineを活かすことで、Parse・Bind・Emitの各フェーズを並列化し、Checkerも複数並べることで高速化を実現しています。 VS Code (Electron) のプロジェクトを tsc と tsgo それぞれで実行した際の所要時間とCPU使用率の差を見せていただいたデモでは、マルチスレッドの活用やCPU使用率の変化が一目で分かり、なぜ大幅な高速化を実現できたのか直感的に理解できました。 発表のなかで繰り返し強く呼びかけられていたのが、コミュニティからのフィードバックでした。「ぜひbetaやnightlyを試してほしい」「VS CodeのNative Preview拡張を入れてほしい」「クラッシュやコンパイル挙動の変化、特にAPIへの意見を送ってほしい」と呼びかけていました。 過去1年でコミュニティから1141件のIssueと1487件のマージ済みPRが寄せられ、テレメトリ経由のクラッシュ情報も含め、利用者からの報告が開発の方向性を支えていることが伝わってきました。 私たちのチームでは、すでにコミット時のフックで tsgo を試験的に採用しています。今後は開発フロー全体への導入を進めながら、検知した問題は積極的にフィードバックを送っていきたいです。 ファインディでも従来からOSSへのIssue起票やPull Requestの作成、メディア企画を通じた寄付などの形で支援を続けてきましたが、TypeScriptのように多くの利用者を抱えるプロジェクトでは、利用者一人ひとりの報告こそが大きな貢献になることを再認識しました。 これまで断片的にしか追えていなかったTypeScript 7について体系的に理解でき、とても学びの多い発表でした。社内にもぜひ共有していきたいと思います。 【甲斐】tscからtsgoへ ── DenoのTypeScript基盤はどう変わったか 2026.tskaigi.org Denoのmaguroさんによる、DenoのTypeScript基盤を tsc から tsgo へ移行する取り組みについてのセッションです。 元々DenoはTypeScriptをフォークしたパッケージを使用し、Deno Rust側と必要な情報をやり取りし、Deno固有の概念を tsc が解釈できるよう、 tsc にパッチを当てたものをDeno binaryの中に埋め込んでいました。 tsgo への移行の最初のアプローチは tsgo をフォークし、Deno固有の概念を tsgo に渡せるようにするアプローチでした。 tsgo はDeno固有の概念をそのまま解決できないため、Deno Rust側で処理できるよう対応しています。LSP対応のコスト、フォークしたパッケージのメンテナンスコストが高く、現在はフォーク版ではなく公式のTypeScriptパッケージを利用するアプローチが試みられています。 TypeScript向けにDenoの依存と型をローカル生成することで、パッチを当てずにDeno固有の概念を解釈できる構成にしています。 特に印象的だったのは、DenoのWeb標準の哲学を少し曲げてでもTypeScriptで扱える形に寄せていった点です。Deno binaryの中→Deno binaryの外→Deno projectの外へTypeScriptパッケージが押し出されており、フォークによる運用コストの増加を避けつつ実行可能なアプローチをとっています。 型チェックを使用したい他のライブラリも同様にフォーク以外の選択肢を模索しており、方向性は同じだがそれぞれ異なるアプローチになっていることが興味深かったです。 普段Denoは使用していませんでしたが、現在の形に辿り着くまでにどのような意思決定があったかを見ていくことで、ここに至るまでの課題や意思決定ごとのトレードオフを学ぶことができ、現在の思想を理解する助けとなりました。 今後もツールチェーンやライブラリの意思決定の背景を学ぶ機会を定期的に設けていきたいなと思います。 【千田】Oxlint は ESLint / typescript-eslint を置き換えられるか？ 2026.tskaigi.org 株式会社うるるの藤田翔雅さんによる、OxlintがESLint / typescript-eslintをどこまで置き換えられるのかを整理したセッションです。 特に印象的だったのは、Type-Aware Linting（型情報を使ったLint）の有無でパフォーマンスが大きく変わる点をベンチマークで示していたことです。 型情報を使わない比較ではESLintの8.213秒に対しOxlintは0.304秒と約27倍速く、型情報を使うルールを有効にしてもESLintの16.121秒に対しOxlintは0.807秒と約20倍速いという結果でした。 型情報を使わないLintが構文解析だけで完結するのに対し、型情報を使うLintはプロジェクト全体の型グラフ構築（ tsc / tsgo ）を必要とするためボトルネックになる、という構造的な解説も理解の助けになりました。 導入判断についても踏み込んでおり、型情報を使わないLintであればOxlintは主要ルールを十分カバーしており移行は現実的である一方、 oxlint-tsgolint によるType-Aware Lintingはまだ非安定版であること、カスタムルールを抱えるプロジェクトでは移行コストが上がることなど、現場目線のトレードオフが具体的に語られていました。 結論として、非Type-Aware LintingであればOxlintへの移行を推奨するというメッセージが明快でした。 私たちのチームでもESLint + Prettierを利用しており、CIの実行時間は継続的な課題です。すでにOxc系（Oxlint + Oxfmt）への移行を計画しており、既存のプロダクトはType-Aware Lintingに依存しない構成となっています。 本セッションの「非Type-Aware LintingならOxlint移行を推奨」という結論は私たちの状況に当てはまり、実際の移行計画に重ねて考える良い機会になりました。 【大石】CfP登壇: TypeScript 6.0での型推論修正を追う 当日のCfP枠では、大石が「プロパティの順序で型推論が壊れる!? TypeScript 6.0の修正からContext-Sensitivityの仕組みを追う」というタイトルで登壇しました。 プロパティの記述順序を入れ替えるだけで型推論が壊れる挙動を入口に、TypeScript 6.0でマージされたPRの中身まで踏み込んだ内容です。詳細は別記事にまとめていますので、あわせてご覧ください。 tech.findy.co.jp speakerdeck.com ファインディの活動 ファインディはGoldスポンサーとして協賛し、ブース出展という形で支援しました。 ブースでは「よく使うユーティリティ型」をテーマにしたアンケート企画を実施しました。普段の開発でよく使うユーティリティ型を選んでいただく内容で、2日間かけて多くの方に投票いただきました。 TSKaigi2026始まりました！入口すぐです！ お待ちしております🌟 #TSkaigi2026 #tskaigi pic.twitter.com/ecf1Zzok0V — いわさき@Findy DevRel (@iwasakitchen) 2026年5月22日 x.com アンケートの最終結果はこちらになります。たくさんの投票ありがとうございました。 TSKaigi 2026改めて2日間ご参加いただき、ありがとうございました！よく使うユーティリティの「型」は？の最終結果です！😊🎊 #TSkaigi #TSkaigi2026 pic.twitter.com/0Nt4xun2bQ — いわさき@Findy DevRel (@iwasakitchen) 2026年5月23日 x.com アンケート結果 総数：480票 順位 ユーティリティ型 割合 票数 1位 Record<Keys, Type> 33.3% 160票 2位 Pick<T, Keys> 17.7% 85票 3位 Readonly<T> 14.6% 70票 4位 Partial<T> 9.4% 45票 5位 ReturnType<T> 8.8% 42票 6位 Exclude<T, U> 4.2% 20票 7位 Extract<T, U> 2.5% 12票 8位 NonNullable<T> 2.5% 12票 9位 Awaited<T> 1.0% 5票 - その他 6.0% 29票 その他内訳 ユーティリティ型 票数 その他・使っていない 22票 Omit<T, Keys> 5票 Beautify<T> 1票 & 、 | 1票 加えて、マーケティング担当のメンバーがAIを活用して自ら開発したルーレットアプリと、ファインディオリジナルのノベルティをご用意し、立ち寄っていただいた方に楽しんでいただきました。 さいごに セッションは多岐にわたるなかで、私たちが特に注目したのはGoによるコンパイラの再実装（コンパイラ本体のネイティブ化）、tscからtsgoへの基盤刷新（他ランタイムによる採用）、Rust製Linterの可能性（周辺ツールへの波及）でした。 3つを通して、TypeScriptエコシステムがNative実装へと動いている流れを実感する2日間となりました。TSKaigiはとても温かい素敵なコミュニティで、いち参加者としても多くの学びと交流の機会を得ることができました。 カンファレンスの開催にあたりご尽力いただいた、運営スタッフの皆様、関係者の皆様、登壇者の皆様に感謝申し上げます。 お知らせ 同日参加したファインディのDevRelメンバーによるレポート記事も公開されています。あわせてご覧ください。 note.com TSKaigi 2026のアフターイベント「TSKaigi Night talks 〜after conference〜」をスポンサー企業9社で共催します。当日のCfP枠で採択されなかった知見もコミュニティへ還元することを目的としたイベントです。 ファインディからは千田が「OSSのUIライブラリでESLintのカスタムルールを作っている話」、甲斐が「Temporal - TypeScript 6.0で始める新しい日時API」というテーマで登壇予定です。 2026年6月10日(水)19:00から、ファインディのイベントスペースにて開催します。TSKaigi 2026に参加された方も、参加できなかった方も、ぜひお越しください。 findy.connpass.com ファインディでは一緒に働くメンバーを募集しています！ 興味がある方はこちらから ↓ herp.careers
動画
該当するコンテンツが見つかりませんでした
