多くのライブラリは利便性のためにたくさんの機能を持っていて、その全てを活用するユーザーはほぼいません。一般的なライブラリにおいては、その中から必要な機能のみをバンドルに含めるための設計プラクティスが普及しており、Firebase JS SDK v9 での変更はその代表例でしょう。しかし、コンポーネントライブラリではそのようなプラクティスが発達しておらず、多くのアプリケーションでバンドルサイズに無視できない影響を与えています[1]。 そこで、バンドルサイズを削りやすいコンポーネント設計を考えます。ここでは例として、以下のようにフェードインするタグコンポーネントを Framer Motion を使って実装することを考えます[2]。フェードインの有無は何らかの方法で切り替えられるものとし、フェードインしない場合に、その関連コードをバンドルから削るようにします。 ❌ Boolean プロパティで切

大きめのテーマです。もしかしたら「うちでは書いた JS をそのまま配信してるぜ〜」って人もいるかもしれないでが。 最近の Web フロントエンド開発では、書いた JavaScript をそのまま動かさないことが多い 最近のフロントエンド開発ではエンジニアが書いた JavaScript をそのままブラウザで動かすことはほとんどないかもしれません。 例として最近流行のフレームワークを考えてみましょう。Next.js や Remix、Nuxt.js など、いずれも内部的にトランスパイラやモジュールバンドラを使い、エンジニアが書いた JavaScript を別の形へと変換してからユーザーのブラウザで動かすような仕組みになっています。 一昔前だと Next.js のようなフレームワークが今ほど発展していなかったこともあり、webpack や Babel を直接使っていたと思いますが、それも同じです。

現在注目されているサーバーサイドJavaScriptランタイムといえば、Node.js と Deno と Bun の3つが挙がると思います。この記事ではそれぞれのランタイムを比較し、将来的にどのような使い分けをしていけばいいのか考えます。 Node.js と Deno と Bun の現在 npmライブラリにはすべてのランタイムが対応 Node.js：当然npmライブラリには対応しています。 Deno：npmパッケージを配布するCDNや、npmインポートを使うことで対応しています。 Bun：対応しています。 「Denoが急に方針転換をしてnpm対応を始めた」というのはよくある間違いです。 Big Changes Ahead for Deno（Denoの今後の大きな変化）というブログタイトルが「Denoが大幅な方針変更」というタイトルに翻訳されて日本語記事が出たため、急に方針転換をしたと誤解さ

アドベントカレンダー飽きてきて文章が適当になってきている気がする。 概要 ESTree とは JavaScript の AST の仕様です。 https://github.com/estree/estree で Markdown として管理されています。 AST を表現する独自の構文(README では AST Descriptor Syntax として説明されている)を使って、JavaScript の各構文の AST の形を定義しています。 たとえば ArrayExpression (配列リテラル) の定義はこのようになっています。 interface ArrayExpression <: Expression { type: "ArrayExpression"; elements: [ Expression | null ]; } 1 行目の <: は implements のような意