ゼロランタイムCSS in JSとは？結局、何を使えばいい？- フロントエンドの現在 -
はじめに ~CSS in JSの終焉とゼロランタイムへの移行~ フロントエンドの技術は目まぐるしく変化しています。 そんな中で、フロントエンドフレームワークにおいてはReactが軍配を上げており、cssにおいてはCSS in JSが主流になりつつあります。 余談ですが、筆者はかつてはcssの命名や設計、CSS Lint等々多岐に渡り効率的なCSSの運用について頭を悩ませていましたが、CSS in JSのemotionとMUIのようなコンポーネントライブラを使うことが多くなり、css周りについて考えることが無くなり開発が楽になりました。最近のプロジェクトではcssやscssファイルがプロジェクト内に存在していないような状況です。 しかし、なんと既にCSS in JSがオワコンと言われ始めているではないですか！なぜオワコンと言われているのか理由を探ってみたところ以下の記事を見つけました。 ここ
サーバサイドのJavaScriptランタイム「WinterJS」登場。Rustで書かれ、WebAssembyにコンパイル可能なService Workerサーバ
サーバサイドのJavaScriptランタイム「WinterJS」登場。Rustで書かれ、WebAssembyにコンパイル可能なService Workerサーバ WebAssemblyランタイム「Wasmer」の開発元として知られているWasmer社は、新しいサーバサイドのJavaScriptランタイム「WinterJS」を発表しました。 Announcing WinterJS: a blazing-fast Javascript Service Workers server written in Rust powered by SpiderMonkey ❄️https://t.co/kX7jjJj6qv — Wasmer (@wasmerio) October 27, 2023 WinterJSはRustで書かれた高速なService Workerサーバであり、オープンソースとして公開さ
JavaScriptビルドツールの整理 各ツールの機能と依存関係
フロントエンドのビルドツールが色々ありすぎて、何がどうなっているのかがわかりづらいため、 各ツールができること、特徴 ツール間がどのように依存しあっているか を一気に調べて整理した。(情報は2023/10時点) 概要 ツールの依存関係整理 上層: dev server付きのバンドラ/ビルドツール。アプリ開発者が直接configなどを書いて取り扱うのはここが多いと思われる。(Next.jsに関しては、ビルド機能に着目した場合) 下層: やや基盤的なdev serverなしのツール群。 矢印は、明示的な依存関係を表す。実際には、明示的な依存関係がなくても、下層のツール群は上層のバンドラ(やRollup)に対してプラグインを提供していることが多い。 各ツールのできること整理 ツールごとに、大まかな機能区分で、できることとできないことをまとめた。 各機能区分の定義は次セクションを参照。 ツールごと
Why I Love Remix
kentcdodds.com is completely custom built by me (and team) using Remix. After writing tens of thousands of lines of code using this framework, I have developed a great appreciation for what this framework can do for me and the users of my site. I want to tell you about some of it. In a sentence Here's the core reason I love using Remix to build websites: Remix enables me to build amazing user expe
monorepo開発を快適にするツール選定
先日、location-stateというパッケージについての記事を公開しました。 履歴に基づいて状態を復元できるReact系ライブラリで、現在はNext.jsを重点的にサポートしています。このライブラリの構成はcoreとなる部分とNext.js依存な部分を切り離しscoped packageとし、内部構成もこれに合わせていわゆるmonorepo構成で開発を行なっています。 @location-state/core: coreとなる部分 @location-state/next: Next.js依存な部分 この記事では、monorepoのパッケージ開発を快適にするために実際に採用したツールを紹介していきます。本稿で紹介するツールは以下になります。 pnpm turborepo tsup changesets Renovate pnpm まずパッケージマネージャーですが、個人的に最近はpnpm
AdminJS - the leading open-source admin panel for Node.js apps | AdminJS
Enter the new era of AdminJS! Our system leverages AI to effortlessly generate text. Simplify your product database management with just one click. Check demo of AdminJS Filled with tons of features The out-of-the-box version of AdminJS is pretty powerful, but its in-depth customizability is where it really shines. With a basic knowledge of React and Node.js, you can change nearly every behaviour
PlaywrightのVSCode拡張を使って効率的にテストを書く
この記事では、Playwright の VSCode 拡張を使って GUI 操作のみでテストの記録や実行する方法について紹介します。 Playwright の VSCode 拡張とは？ Playwright の VSCode 拡張は、Playwright の作成元である Microsoft が公式に提供している拡張機能で、VSCode 内で直接ブラウザテストの記録や実行を支援するための便利なツールです。 GUI 操作を中心に、テストの記録や実行を手軽に行うことが可能となります。 VSCode 拡張のインストールは、以下のリンクから行うことができます。 VSCode 拡張を活用してテストを書く 本記事では、シンプルな ToDo アプリを例にテストの作成方法を説明します。Playwright のインストール方法は、公式ドキュメントをご参照ください。その後、VSCode に Playwright
Biome と ESLint の lint ルールの互換性
Biome では、現在約 150 個程度の JavaScript・TypeScript に関する lint ルールを実装しています。 これらのルール多くは既存の ESLint 関連で実装されているルールと同じものになっているのですが、ルールの名前が異なることもあり、その対応関係がわかりにくくなっています。 そこでこの記事では、フロントエンド開発をする場合によく設定していそうな次の lint ルールについて、Biome で実装されているかどうかの対応表を紹介します。 eslint (eslint:recommended) typescript-eslint (plugin:@typescript-eslint/recommended) eslint-plugin-jsx-a11y (plugin:jsx-a11y/recommended) eslint-plugin-react (plugi
Hono + htmx + Cloudflareは新しいスタック
この記事は以前7月に自分で書いた「Hono + htmx + Cloudflare is a new stack」という記事を一部修正し、訳したものです。 Hono + htmx + Cloudflareは新しいスタック 以前、バックエンドエンジニアだった身からすれば、Reactは複雑だと感じることがあります。さらに（私はフレームワーク開発者なのですが）フレームワーク開発者にとってはハイドレーションの仕組みを作ることは厄介です。しかし、しばしばReactを使うことになります。 Reactの優位な点の一つは「JSX」です。最初見た時、JSXは奇妙に思えました。「なんでJavaScriptの中にHTMLのタグが入っているんだ！」。しかし、一度慣れると、JSXは柔軟で、書きやすいことに気づきました。 今日はこれから、JSXをサーバーサイドのテンプレートとして使う技術スタックを紹介します。これはつ
ESLint を使い倒す（おすすめルール紹介）
前書き ESLint は JavaScript, TypeScript のための静的検証ツールです。 ESLint を活用することで、コーディング規約やベストプラクティスを機械的に強制することによりコードレビューの手間を省き、本番環境でのエラーやパフォーマンスの悪化を抑制することができます。 TypeScript を使っているプロジェクトでは、パーサーを適切に設定すれば型情報を用いたより精密な静的検証を行うこともできます。 eslint を使う際、 eslint:recommended, plugin:@typescript-eslint/eslint-recommended などの各 eslint plugin の推奨 config のみを使って済ませたり、 eslint-config-airbnb などの config のみに頼ることも多い印象ですが、 recommended conf
【Jest】モック関数入門
はじめに Jestではじめるテスト入門や フロントエンド開発のためのテスト入門が届き、 テスト欲が高まっている土屋です。 Jestでの単体テストを行う際に、 「似たようなメソッドがあるけど、何が違うんだ？」という疑問が生まれたため、 前述の2つの本を参考にJestでのモックの方法を整理していきたいと思います。 モックとは xUnit Patterns Test Doubleより引用 モックとは、テスト対象の一部もしくは全てを代替オブジェクトで代用する手法であり、 広義の意味では「テストダブル」と呼ばれています。 xUnit Patterns によると、テストダブルには ダミー: コンパイルを通すために必要なコンポーネント スタブ: 代替オブジェクトで設定した値を返す スパイ: パラメータ、呼び出された回数、戻り値などを記録 (狭義の意味での)モック: 代替オブジェクトで期待する内容の検証
乱立したpackage.jsonのエントリーポイントフィールド
この記事は夏のブログリレー17日目の記事です。 こんにちは、19Bの翠(sappi_red)です。普段はSysAd班で活動しています。Viteのチームメンバーだったりもします。 npmからインストールしたパッケージをモジュールバンドラーで使えないことに遭遇したことのある人は少なくないでしょう。 この記事ではそれが発生する要因の一つである、package.jsonのエントリーポイント用フィールドについて書いていきます。 モジュールバンドラーとトランスパイラは意味が異なるものですが、モジュール形式の変換においては境界線が非常に曖昧になるため、この記事ではまとめてバンドラーと呼ぶことにします。 モジュール形式 話を進める前に、前提となるモジュール形式という概念について説明しておきます。 JavaScriptでは元々、プログラムを複数のモジュールに分割する標準仕様が存在しませんでした。そのため、標
クックパッドのフロントエンド CSS in JS をゼロランタイムに切り替えました - クックパッド開発者ブログ
こんにちは。レシピ事業部のkaorun343です。我々のチームではレシピサービスのフロントエンドを Next.js と GraphQL のシステムに置き換えている話 - クックパッド開発者ブログにて紹介したとおり、レシピサービスを Next.js ベースの新システムへと移行しています。今回は、この新システムのCSS in JSをEmotionからゼロランタイムのvanilla-extractへ変更した話です。 vanilla-extract.style 背景 以前書いた レシピサービスのフロントエンドに CSS in JS を採用した話 - クックパッド開発者ブログでは、CSS in JSライブラリとして Emotion（@emotion/react）を採用した経緯と開発環境整備を紹介しました。採用理由としては以下の通りでした。 セレクタに一意なIDが割り振られるので、スタイルを適用した要
eslint-plugin-securityを導入してみるメモ📝 - Madogiwa Blog
Rubyだとbrakemanのようなライブラリがありますが、 github.com JavaScriptでもこういうセキュリティ周りの静的解析系のライブラリがあるのかなと探してみたらeslint-plugin-securityなるものを見つけて個人のサービスに導入してみたのでメモ📝 github.com 導入方法はREADMEの通りですが、以下の通りinstallしてpluiginsに追記するだけです。 $ npm install --save-dev eslint-plugin-security "extends": [ "eslint:recommended", + "plugin:security/recommended" ] 実際に検知できるルールは以下に記載されています。 https://github.com/eslint-community/eslint-plugin-sec
npm、yarn、pnpm それぞれのコマンドを覚えるのに疲れた方へ - Qiita
はじめに 皆さんはnpm, yarn, pnpmどのPackage Managerを使っていますか？ yarnしか使わない！という方もいるかもしれませんが、pnpm評判いいみたいだし使ってみようかなとか、チーム開発では安定のnpmなんだよなとか、複数のPackage Managerを使用するケースって少なくないかと思います。 そういった場合、それぞれのコマンドを覚えるのも面倒ですし、プロジェクトに応じて頭の切り替えをしないといけないのは大変です。 本記事は、そういった悩みを解決する方法を紹介します。 ni niはnpm,yarn,pnpm,bunに対応していて、それぞれのlockfileを読み取って、適切なコマンドを実行してくれるPackage Managerです。 niのコマンドは短く、わかりやすいのですぐ覚えられると思います。 ちなみに、作者はVueやNuxt、Viteなどのコアチーム
なんでbun installは速いのか？
A global install cache. bun installを実行すると ~/.bun/install/cache/ 以下にnpmレジストリからダウンロードされたファイルの実体が展開されキャッシュされる(--cache-dirでパスを変更できる)。 キャッシュにはパッケージのバージョンごとのディレクトリとlatestのシンボリックリンクがある。これらのファイルを使ってbun install時に該当するバージョンのダウンロードを省く(--forceで再ダウンロードする)。 このため一度bun installしてlockfileが作成されると次はオフラインでinstallを実行しても成功する。 node_modules/を削除しても~/.bun/install/cache/からファイルを取ってくるのでネットワークアクセスをしない。
App Router時代のゼロランタイムCSS in JSに何を使えばいいの？
はじめに こんにちは！ 犬専用の音楽アプリ オトとりっぷでエンジニアしています、足立です！ この記事では、Next.jsのReact Server Components(RSC) で使用可能なゼロランタイムCSS in JSライブラリを比較します。 目次 モチベーション 使えるライブラリたち 選定基準 選定結果 比較結果 書き味 パフォーマンス Dynamic Styling 結論 モチベーション みなさん、Next.jsのReact Server ComponentsのStyleをどうやるか問題に悩んでおられますね？ 私もどれを使えばいいのかわからずNext.js公式に見に行くと、App Routerで使用できるものとして、以下のライブラリを上げています。 が、React Server Componentsではnot supportedと記載されており、まだまだ未整備な状況のようです。
Bun workspace で始めるモノレポ生活
Bun では `package.json` の `workspaces` を使用することでモノレポの管理が可能です。この記事では Bun によるモノレポを試してみます。 Bun はパッケージマネージャーとしても利用できるので、npm の workspaces によるモノレポ管理も可能です。モノレポとは、複数のパッケージを 1 つのリポジトリで管理することです。モノレポを利用することで、同レポジトリ内のパッケージを互いに参照したり、node_modules をシェアしてディスク容量を節約するといったメリットがあります。 この記事では、Bun workspace を利用してモノレポを管理する方法を紹介します。 Bun workspace の使い方 workspace ではディレクトリのルートレベルに、各パッケージを管理するためのルートパッケージが必要です。ルートパッケージは通常 depende
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - joshmarinacci/node-pureimage: Pure JS implementation of the HTML Canvas 2D drawing API
Storybookを書くだけでリグレッションテストが 実行される世界へようこそ
