最近、Boshen さんが開発している Oxc に注目しています。 社内で Oxc の近況を slack に投稿していたところ、「Oxc は Rome で話題になっていますか？」や「Oxc はうまくいくと思いますか？」と聞かれたことで Rome の現状を整理するいいきっかけになったので、記事に残しておこうかなと思います。 Rome と Oxc の違い Rome と Oxc はどちらも linter、formatter、transpiler などを提供するつもりではあるので、ユーザーからみた違いは分かりにくいかなとは思います。現時点での大きな違いは、次の２点だと思っています。 プロジェクトのスコープ Rome: JS/TS に限らず Web 開発に関連する言語全般にツールを提供することを試みている Oxc: JS/TS に関するツールにフォーカスしている 提供するツールの拡張性に対する考え方

欲しい物がなければ、自分で作るしかないシリーズ なぜ作ったか .svelte のテンプレートは .tsx と違って JS/TS としてのプログラミング言語としての構文の影響下になく、プログラムをあまり書かないマークアップエンジニアとの連携に便利で気に入っています(リスト表示に .map で目を回すぐらいの人を想定しています)。シンプルな構文で TypeScript の型もつきやすく、IDE支援もそこそこで、 モダンな vue テンプレートという感じです。 しかしながら、 GitHub のオープンソースのトレンドを見ればわかるように、フロントエンドのエコシステムは基本的に jsx/tsx を中心に回っています。そして現代の View 層のライブラリは(WebComponents がライブラリ間のブリッジとして失敗しているので)同じライブラリ同士でしか接続できず、この現状に不満を持っていました

この記事でのusing宣言の動作はBabelのtransform及びes-shimsのpolyfill実装に依存しており、実際のV8エンジンやTypeScriptのトランスパイル出力の挙動とは異なる可能性があります。 以下の挙動がusing宣言に対応している処理系の実際の挙動と異なる場合はコメントをいただけると幸いです。 導入 先日、Twitterでこんなツイートが回ってきました。 TypeScript 5.2で新しい「using宣言」が追加されるというものです。 しかも、TypeScriptの独自構文かと思いきや、JavaScriptのStage 3のProposalをTypeScriptで先行実装するという通常のTypeScriptの実装プロセスに則ったものでした。 新しい変数宣言の追加はES 2015(ES6)の「let」「const」以来でなんと8年ぶりで、JavaScript/T

GitHub Copilot が読み込む情報 GitHub Copilotが読み込む情報は以下の通りで、トークン数の制限が許す限り上から順番に Context に埋め込まれるとのこと。 言語マーカー:使用されているプログラミング言語情報 パスマーカー:プロジェクト内の現在のファイルへのパス情報 隣接タブ:他の非アクティブなオープンタブ上のデータ a. 隣接したタブから順番に Context に挿入されるそうです。最大20タブまで。 兄弟関数:現在のカーソル位置の後のデータ 回収:コードベース中の、他の場所のコード

自分の事前知識として、先日 GitHub Copilot の中の人が Copilot がどのように動いているか解説してくれるイベントに参加して内部について概要を知っていた。 それもあって、mizchi さんの考察が合理的、かつ、的を射ていることが明確に感じられた。

Copilot をオープンベータ直後から長く使っていて、また補助的に ChatGPT も使いながらコードを書いていて、なんとなくコツがわかるようになってきた。 自分は生成モデルのことは表面的な理解しかしてない。雑にバックプロパゲーションの実装の写経したり、Transformer の解説とかは読んだが、にわかの域を出ていない。 あくまで利用者として生成モデルから吸い出したプラクティスになる。 基本的に TypeScript と Rust での経験が元になっているが、他の言語にも適用できる話ではあると思う。自分は TypeScript はかなり得意だが、 Rust はあんまり書けるわけではなく、Rust の学習で ChatGPT を頼ろうとして失敗しているというステージ。 Copilot / ChatGPT とどう付き合うか まず、前提として ChatGPT も Copilot も、コード生成

みんなお世話になっている TypeScript のコードを読みたいと思ったことはないだろうか。読んだ。 一週間ぐらいかかった。完全に読み切ったとは言えないが、概要は掴んだ。 なかなかに複雑でドメイン知識を得るのが難しかったので、これから読む人向けに、登場人物や概念を整理して紹介したい。 読んだのは 2023/6/8 時点で git clone したコード。 最初に: 自分のゴール設定 複数ファイルにまたがった参照を、 TypeScript の Language Service が提供する findReferences() や findRenameLocations(), goToDefinitions() を使って、インクリメンタルに書き換えたかった。 Terser を使うと、今触ってるオブジェクトが何で、何のメンバを書き換えたかの情報が残らない。これを TypeScript のレイヤーで

TypeScript の Compiler API を型定義だけで雰囲気で使っていたが、 typeChecker(型解析器) の気持ちが全然わからないので本体を読むことにする。 まず最初に、素朴に git clone したら重すぎたので、特にPRとかするのでなければ --depth 1 したほうがいいと思う。

$ npm install @mizchi/declass $ npx declass input.ts # -o output.ts export class Point { x: number; y: number; constructor(x: number, y: number) { this.x = x; this.y = y; console.log("Point created", x, y); } distance(other: Point) { return Math.sqrt(Math.pow(this.x - other.x, 2) + Math.pow(this.y - other.y, 2)); } } export class Point3d { constructor(public x: number, public y: number, public z:

React や Svelte でコンポーネントベースで開発するとき特有の CSS ノウハウってあんまり効かない気がする Twitter に書いたら反響があったので、自己流だけどまとめておく React Component の管理単位と、CSS としてのレイアウトの管理ポリシーは違うよね、みたいな話をマークアップエンジニアに時折されるが、そんな話は無視して完全一致させる。そういう星のもとで開発している コンポーネントの分類 ロジックコンポーネント レイアウトコンポーネント ブロックコンポーネント インラインコンポーネント 定義 ロジックコンポーネント Provider や hooks などのデータ処理だけを扱い、子に渡すコンポーネント 一切の CSS や DOM 実体を持たない レイアウトコンポーネント レイアウトコンポーネントは複数の子ブロックコンポーネント(または slot)を持ち、子ブ

これだけみると LibC がよく見えますね。 オープンソースのライブラリ比較や、エンタープライズな SaaS が競合に対する優位を見せたいときに星取表が使われることが多いです。 中立な立場でライブラリを選定する過程として出てくることがあります。 自分はこれに全く意味がなく、むしろ競争的な立場では出した側が負けるものと認識しています。 星取表を作る側の意図 よく見かけるパターンがこれです。 開発自体は長いため機能が豊富だが性能に劣る先発が、後発を貶めている 恣意的な項目選定で、そもそも負けている そもそも比較対象としての土俵が違う(全部入りのフレームワークと単機能なライブラリの比較) 特に 1 と 2 の組み合わせが多く、この裏では非機能要件で圧倒的に負けていることが多いです。例えば A は機能は豊富だけどビルドに 30秒で、Bは機能は足りないけど3秒だといった場合、多くの場合ではまず B

はじめに 2024年4月1日から障害者差別解消法の方針が改定される。この法律は「障害を理由とする差別の解消を推進する」ために、以下の3つを行うこととしている。 不当な差別的取扱いの禁止 合理的配慮の提供 環境の整備 「合理的配慮の提供」とは、障害のある人から「社会の中にあるバリア(障壁) を取り除くために何らかの対応が必要」との意思が伝えられたときに、行政機関等や事業者が、負担が重すぎない範囲で必要かつ合理的な対応を行うこと。 「合理的配慮の提供」は、これまで行政機関等は義務、事業者は努力義務とされていたが、改正法により、2024年4月1日から事業者も義務化されることとなる。 これによって、事業者のWebページにも何らかの配慮が義務となる。「合理的配慮の提供」が義務化されることで、Webサイトやアプリケーションの分野では、どのような対処が必要となるのか、2024/4の方針改定までに取り組む

いまさら気づいたけど Headless 系のUIライブラリが一番 AI と相性いいのではないか。 ロジックはプログラマで書けて自由度高いし、コンポーネントのネスト構造から意図を読み取れるだろうし、class 名は自由に書けるから意図を表明しやすい。 それをプロンプトとして ChatGPT or Codex にそのまま投げて書かせる、ができる。 というわけで vite + react + radix-ui + vanilla-extract で実験してみた。 プロンプト あなたは凄腕のマークアップエンジニアです。 radix-ui は Headless UI ライブラリで、UIとしてのセマンティクスのみを持っています。 次のコードは React + radix-ui + vanilla-extract で書かれた React コンポーネントです。 // Popover.tsx import

TypeScriptの型定義ファイルから積極的な圧縮を行うための @mizchi/optools をリリースした。まだ実験中だが、結構動くはず。使う場合は自己責任で。 追記: optools を packelyze に rename した。これは optools という CLI 名が ImageMagick の提供するコマンドとぶつかったため。 試行錯誤の過程は https://zenn.dev/mizchi/scraps/1bdf01f5efb147 にある。 このライブラリは、自分の所属する Plaid の業務時間中に作成した。 想定ユーザー ライブラリ作者 ビルドサイズ厳しいフロントエンド開発者(サードパーティスクリプト等。自分が業務で作った理由がここ) リスクとってでもビルドサイズを縮めたいフロントエンド作者 動機 世の中な TypeScript で書かれたコードは、その型情報を使

10秒で概要 10万件のデータをサジェストするAutocompleteなSelectBoxを作りたい。 しかし、1万件を超えたあたりから通常のAutocompleteではレンダリングに時間がかかる。 以下の方針が有る。 react-windowによるレンダリング以外の範囲の仮想化 フロントエンドではデータを保持せず、入力値に応じてSearchのAPIコールを実施する Reactのレンダリングによる課題 Reactのレンダリングは、大まかに以下のフローで行われます。 Triggering a render 新規画面への描画時、またDOM要素の差分を検出したことをTriggerがとして、レンダリングが発生します。 Committing to the DOM 描画要素に違いがあるDOM要素のみ、DOMノードを変更します。 Autocompleteで表示するデータである<li>要素についても当然D

作った。 lightweight-zod だから lizod。 npm install lizod -S で使える。 tl;dr 各種フロントエンドや Cloudflare Workers で zod のビルドサイズが邪魔になっている メソッドチェーンと便利なユーティリティを全部捨てた zod 風のバリデータを作った zod の 57kb に対して lizod は 1kb 以下 これが動く // Pick validators for treeshake import { $any, $array, $boolean, $const, $enum, $intersection, $null, $number, $object, $opt, $regexp, $string, $symbol, $undefined, $union, $void, type Infer, type Valid

まだライブラリ化してないのと、フルパス対応してないけど、いじれば使えると思う。 これは何 こういう感じに fetch に型がついて動く import { type TypedFetch, JSON$StringifyT, JSON$ParseT } from "./typed-fetch"; const stringifyT = JSON.stringify as JSON$stringifyT; // こんな感じの記法で型情報を与える const fetch = window.fetch as TypedFetch<{ "/api/:xxx": { method: "GET"; bodyType: { text: string; number: number; boolean: boolean }; headersType: { "Content-Type": "application/

これはなにか cloudflare スタックを使ったマイクロフロントエンドの提案。 特に service-binding を活用することで異なるサービス(ここでは cloudflare worker)から配信されるフロントエンドを統一的にSSRしつつ、開発単位を分離している。 RTT最適化のために qwik で書かれているが、SSR を意識しなければ他のライブラリを採用しても良い。 $ tree . -I node_modules . ├── README.md ├── body │ ├── package.json │ ├── public │ │ └── favicon.ico │ ├── src │ │ ├── Body.css │ │ ├── entry.ssr.tsx │ │ └── root.tsx │ ├── tsconfig.json │ ├── vite.config.t

はじめに この記事は、Cloudflare が提唱する Fragment Piercing (フラグメント・ピアシング) の記事(Cloudflare Workersによるマイクロフロントエンドの段階的な採用)を読んだ筆者が、そこから得たアイデアとそれをPoC（概念実証）している「コンポーネント配信システム」についてドキュメント化したものである。 この記事で取り上げられているシステムなどは、まだ実用段階に達していないものが多く含まれている。 デザインシステムとコンポーネントの配信 近年、デザインシステムを構築したり公開する企業や組織が増えている。 「デザインシステム」の価値は、Storybookのドキュメントに次のように示されている。 デザインシステムは複数のプロジェクトを横断してチームが複雑で、丈夫で、アクセシビリティの高いユーザーインターフェースを構築するための再利用可能な UI コン

Cloudflare Workers を活かしきるスタックを考えた(remix+d1 on pages-functions) + 残タスク このスクラップ で試行錯誤していたまとめ。 最終形はここにアップロードした。 docs の下に、このリポジトリを生成した手順、セットアップ方法、リリース方法を書いてある。 (remix-validated-form や vitest のテストの追加でもうちょっといじるとは思う) なぜ cloudflare-workers + d1 のポテンシャルは最強で、近い未来、開発者|個人開発者の銀の弾丸になると思っているのだが、それを活かす開発スタックが知られていない(要出典)。この記事では GW の間に自分で周辺ライブラリを使い倒しながら選定していった。 2021年 は Fullstack Next.js 元年なので、有望な Next.js 系フレームワークを