サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
ドラクエ3
postd.cc
CSSの新しい:hasセレクタと、これを使用したReactコードの改善方法について説明します。実用的で美しい例とともに。 大昔、とは言ってもCSSが出てきた当初の話ですが、CSSはカスケードする仕組みになっていると教えられていました。それは、Cascading Style Sheetsという名前からも分かります。CSSでは、入れ子のように要素の中の要素を指定し、さらにその中に含まれる要素を指定していくことができます。しかし、その逆はできません。したがって、子要素が親要素にスタイルを適用するには、JavaScriptを使うしかありませんでした。 今までは。 すべての主要ブラウザがCSSの:hasセレクタに対応したことで、親要素を指定できるようになりました。それだけではありません。これは世界が一変したと言えるほどの出来事です。筆者のように、要素の角を丸くするために透過GIFを使用していた時代か
Reactのコアアーキテクチャは、与えられた関数（すなわちコンポーネント）を繰り返し呼び出します。この仕組みはReactのメンタルモデルを単純化し、その人気に一役を買いましたが、同時にパフォーマンスの問題が生じる原因にもなりました。関数のパフォーマンスコストが高いと、アプリの動作は総じて遅くなります。 開発者はReactにどの関数をいつ再実行するか手動で指示しなくてはならなかったため、パフォーマンスチューニングが悩みの種になっていました。Reactチームが最近リリースしたReact Compilerというツールは、コードを書き直すことにより、開発者が手動で行っていたパフォーマンスチューニングの作業を自動化します。 React Compilerはコードに何をするのでしょうか？裏ではどのような処理が行われるのでしょうか？使った方がいいのでしょうか？こうした疑問について詳しく見ていきたいと思いま
:has()疑似クラスは筆者が断トツで一番気に入っているCSSの新機能です。筆者と同じ意見の読者も多いでしょう。少なくとも、State of CSSのアンケートに回答した方の中には多くいるはずです。セレクタを逆向きに指定できることで、これまでできると思いもしなかったようなすごいことがもっと可能になります。 「もっと」と言うのは、すでに多くの人が極めてスマートなアイデアを色々と発表しているからです。以下に一部紹介します。 Using :has() as a CSS Parent Selector and much more（Jen Simmons） Quantity Queries for “islands of elements” with the same class, thanks to CSS :has()（Bramus） Style a parent element based o
登場以来、Reactはアプリケーションのパフォーマンスを最適化するためのツールを多数供してきました。中には極めて有益でありながら、あまり知られていないものもあります。useDeferredValueはその一つです。このツールは、特定の状況においてユーザーエクスペリエンスを大きく左右することができます。⚡ 筆者は最近このフックを使用し、このブログの厄介なパフォーマンス問題を解決したのですが、そのあまりの効果に衝撃を受けました。低性能デバイスでは反則級の改善が見られ、まるで黒魔術のようでした。 useDeferredValueには若干気後れさせるような評判があり、実際かなり洗練されたツールではあるのですが、正しいメンタルモデルで向き合えば恐るるに足りません。このチュートリアルでは、その仕組みと、アプリケーションのパフォーマンスを劇的に改善させる使い方を詳しく説明します。 問題 数年前、筆者は本
クイックサマリー：人工知能がコンピューティングパラダイムの進化をもたらしており、それに伴いデザイナーはより直感的なユーザーインターフェースを開発するチャンスに恵まれています。新しい機能のほとんどは、テキストベースの大規模言語モデルによって実現されているため、グラフィカルインターフェースからチャットボットのような対話型インターフェースへの移行が必要との声が多く聞かれるようになっています。しかし、多くのインタラクションパターンにおいて、対話は優れたインターフェースではないことをかなりの証拠が示しています。最新のAI機能によって、対話だけにとどまらずヒューマンコンピューターインタラクションの未来がどう変わりうるのか、マクシミリアン・ピラスが考察します。 人間とコンピューターのインタラクションのあり方を根本から変えうるような技術革新はそうそうありません。幸運なことに、次のパラダイムシフトは今まさに
「決断の時における最善の選択は、正しいことをすること。最悪の選択は、何もしないことだ。」セオドア・ルーズベルトの言葉です。 人生を左右する可能性のある重要な決断を下すとき、結果が不確実であることや、未知の領域に踏み込むことへの不安から、ひたすらデータを集めては分析を繰り返し、必要以上に考え過ぎてしまう非生産的な悪循環に陥ってしまうことがあります。 想像が膨らんでしまい、最悪のシナリオを想定してそれが最善だと思い込んでしまうこともあれば、頭の中にストーリーを描き、良い選択肢があるにもかかわらず、より良い選択肢があるのではと考えて全て却下してしまうこともあります。 こうした決断の例としては、引越し、退職と起業、転職、企業戦略の大転換などがあります。 恐怖心、完璧主義、怠惰、集中すべき目標の欠如など、理由はさまざまですが、分析ばかりに時間を費やして一向に行動を起こさないでいると、「analysi
none«自動化できるものはすべて自動化されるだろう» - ロバート・キャノン、インターネット法・政策専門家 人工知能（AI）が今年のトレンドであることは紛れもない事実です。AI技術が台頭し、さまざまな業界で急速に普及する中、UI/UXデザイナーやプロダクトデザイナーも当然その影響を受けています。ChatGPTやMidjourney、DALL-E 2（ダリ・ツー）、Stable Diffusionなどの製品はすでにかなり人気があり、筆者の同僚の中にも積極的なユーザーが多数います。 UI/UXデザイナーとして、筆者もChatGPTを作業プロセスに取り入れたことにより、より使いやすいインターフェースの開発能力が格段に向上したことをすでに実感しています。この記事では、ChatGPTの具体的な使い方を示しつつ、ChatGPTを利用することでどのようなメリットを享受でき、いかにして全体的な作業効率を
クイックサマリー：「テストピラミッド」は、自動テストをUI、サービス、ユニット単位に整理することで、開発に自動テストを組み込む方法を示すために作成されました。2012年に定義されて以降、このモデルは次第に使われなくなってきたように思いますが、本当に廃れてしまったのでしょうか。この記事では、最新のテスト戦略を紹介するとともに、今日のソフトウェア開発におけるテストピラミッドの関連性を検討します。 筆者の同僚であるジャン・フィリップ・ピエトルチェクが、かつてコードを書く開発者の責任について、次のように述べました。 none「我々の仕事の成果を最終的に使用する人々は、（中略）我々がただ最善を尽くすだけでなく、実際に機能するものを作ることを期待しているのです。」 — ジャン・フィリップ・ピエトルチェク 彼の言葉は、私たちが書くコードをそれに依存する人々の観点からとらえている点で非常に印象に残りました
私も年を取ったと感じるのは、今年Reactが10年目を迎えたからです。 混乱していた開発コミュニティにReactが初めて紹介されてから10年、以来いくつもの進化を遂げてきました。Reactチームは、急進的な改革ということに関しては躊躇しませんでした。問題に対して、より良い解決策が見つかれば、それを実行してきました。 数か月前、Reactチームは最新のパラダイム・シフトであるReact Server Componentsを発表しました。史上初めて、Reactコンポーネントがサーバーでのみ実行できるようになったのです。 このことに関連してオンライン上では、きわめて大きな混乱が起きています。それが何なのか、どのように機能するのか、利点は何か、そしてSSR（Server Side Rendering）などとどのように連携するのか、多くの人が多くの疑問を抱いています。 私はReact Server
Next.jsを4年間使用してたどりついた、エンタープライズアプリケーションのフロントエンド開発・構築手法 はじめに 目まぐるしく進化するフロントエンド開発の世界では、常に最新の知識や技術をいち早く取り入れることが、エンタープライズアプリケーションの開発を成功させる上で欠かせません。Tailwind CSS、TypeScript、Turborepo、ESLint、React Queryなどを含む強力なツールキットとNext.jsを4年間使用してきた結果、開発に役立つさまざまな知見やベストプラクティスが得られました。この記事では、大企業向けフロントエンドアプリケーションのパフォーマンス、保守性、拡張性を最大限に高める設計・構築手法を紹介したいと思います。 注記：ここに記載する内容はあくまでも個人的な見解であり、筆者が推奨する手法が必ずしも適さない場合もあります。 効果的なエンタープライズ向け
はじめに 目まぐるしく進化するフロントエンド開発の世界では、常に最新の知識や技術をいち早く取り入れることが、エンタープライズアプリケーションの開発を成功させる上で欠かせません。Tailwind CSS、TypeScript、Turborepo、ESLint、React Queryなどを含む強力なツールキットとNext.jsを4年間使用してきた結果、開発に役立つさまざまな知見やベストプラクティスが得られました。この記事では、大企業向けフロントエンドアプリケーションのパフォーマンス、保守性、拡張性を最大限に高める設計・構築手法を紹介したいと思います。 注記：ここに記載する内容はあくまでも個人的な見解であり、筆者が推奨する手法が必ずしも適さない場合もあります。 効果的なエンタープライズ向けフロントエンドアーキテクチャの基本原則 エンタープライズ規模のアプリケーション向けにフロントエンドソリューシ
fetchPriority APIは、リソースの相対的な優先度をブラウザに示すために使用します。fetchpriority属性を<img>、<link>、<script>、<iframe>の各要素に追加するか、Fetch API上でpriority属性を使用することで優先度を設定できます。 ブラウザのロードプロセスは複雑です。ブラウザは、主にリクエストの種類や、ドキュメントのマークアップ内におけるリクエストの位置によってその優先度を判断します。例えば、ドキュメントの<head>内で要求されたCSSファイルの優先度はHighestとなり、defer属性が設定された<script>要素の優先度はLowとなります。ブラウザは、同じ優先度が割り当てられたリソースを、検出した順にダウンロードします。 fetchpriority fetchpriority属性を使用することで、要求されたリソースの優先
この記事では、DOMの測定結果に基づいて要素を変更する方法、useEffectの問題点とuseLayoutEffectによる解決法、ブラウザペインティングとは何か、SSRの役割について説明します。 この記事と同じ内容を扱ったYouTube動画も公開していますので、活字媒体よりも動画視聴を好まれる方はそちらをご覧ください。文字ではなく、アニメーションと音声で同じ概念を解説しています。 この記事は動画形式でも公開しています。 目次 useEffectの問題点とは？ useLayoutEffectでチラつきを解決する 解決策が有効な理由：レンダリング、ペインティング、ブラウザ Next.jsやその他のSSRフレームワークでuseLayoutEffectを実行する ReactにおけるDOMアクセスについてもう少しお話ししましょう。"前回の記事 ReactにおけるRef：DOMへのアクセスから命令型
この記事では、ReactにおいてDOMへのアクセスが必要な理由と、その際にRefがどう役立つのかを見ていきます。また、useRef、forwardRef、useImperativeHandleという3つのフックについて説明し、これらを適切に使用する方法を紹介したいと思います。 この記事と同じ内容を扱ったYouTube動画も公開していますので、活字媒体よりも動画視聴を好まれる方はそちらをご覧ください。文字ではなく、アニメーションと音声で同じ概念を解説しています。 この記事は動画形式でも公開しています。 目次 useRefを使用してReactでDOMにアクセスする 親から子にRefをpropとして渡す forwardRefを使用して親から子にRefを渡す useImperativeHandleを使用した命令型API useImperativeHandleを使用しない命令型API Reactには
フロントエンドパフォーマンスのチェックリスト2021年版（PDF、Apple Pages、MS Word）-後編 目次＃ 前編 準備段階：計画と指標 パフォーマンスを重視する文化、Core Web Vitals、パフォーマンスのプロファイル、CrUX、Lighthouse、FID、TTI、CLS、端末。 現実的な目標の設定 パフォーマンスバジェット、パフォーマンス目標、RAILフレームワーク、170KB/30KBバジェット。 環境の定義 フレームワークの選択、パフォーマンスコストの基準設定、Webpack、依存関係、CDN、フロントエンドアーキテクチャ、CSR、SSR、CSR + SSR、静的レンダリング、プリレンダリング、PRPLパターン。 中編 アセットの最適化 Brotli、AVIF、WebP、レスポンシブ画像、AV1、アダプティブメディア読み込み、動画圧縮、Webフォント、Goog
目次＃ 前編 準備段階：計画と指標 パフォーマンスを重視する文化、Core Web Vitals、パフォーマンスのプロファイル、CrUX、Lighthouse、FID、TTI、CLS、端末。 現実的な目標の設定 パフォーマンスバジェット、パフォーマンス目標、RAILフレームワーク、170KB/30KBバジェット。 環境の定義 フレームワークの選択、パフォーマンスコストの基準設定、Webpack、依存関係、CDN、フロントエンドアーキテクチャ、CSR、SSR、CSR + SSR、静的レンダリング、プリレンダリング、PRPLパターン。 中編 アセットの最適化 Brotli、AVIF、WebP、レスポンシブ画像、AV1、アダプティブメディア読み込み、動画圧縮、Webフォント、Googleフォント。 ビルドの最適化 JavaScriptモジュール、モジュール/ノーモジュールのパターン、ツリーシェイ
クイックサマリー：2021年のWebパフォーマンスを高速化しましょう。 毎年恒例のフロントエンドパフォーマンスのチェックリスト（PDF、Apple Pages、MS Wordに対応）は、指標やツールからフロントエンドのテクニックに至るまで、現代のWebで高速なユーザ体験を生み出すために知る必要があるすべてを提供します。 このチェックリストは2016年から更新を続けてきました。 メールのニュースレターでも、フロントエンドに関する便利な情報をご確認いただけます。 このガイドは、LogRocketに勤務する筆者の友人の厚意によるサポートを受けています。 LogRocketは、フロントエンドパフォーマンスのモニタリング、セッションリプレイ、製品分析を組み合わせ、顧客体験の向上に貢献するサービスです。 また、DOM完了時間、サーバ初期応答時間（TTFB）、初回入力までの遅延時間（FID）、クライアン
写真： Jr Korpa on Unsplash Intro：2021年はこれまでCSSにとって盛りだくさんな一年でした。 CSSワーキンググループはCSSの仕様にさまざまな変更を加え、既存機能を改良するとともに多くの新機能を追加しました。 一部のブラウザには、すでに実験的に実装されているものもあります。 ブラウザベンダーは、新機能のサポートだけでなく、開発者を悩ませるブラウザの互換性に関する5大問題（#compat2021）の解決にも注力しています。 2021年もそろそろ終わりに近づいているので、今回は2022年に実装されそうなCSS機能を紹介したいと思います。 (※訳注：翻訳元の記事は2021年12月27日公開) 目次 はじめに 注目の新機能（クロスブラウザ対応） コンテナクエリ カスケードレイヤー カラー関数 新しいビューポート単位 :has()擬似クラス overscroll-be
WebAssemblyは今、転換点にあります。今後数年間で、コンテナ化からプラグインシステムやサーバレス・コンピューティング・プラットフォームに至るまで、IT業界全体でWebAssemblyの導入が増えると筆者は予想しています。この記事では、WebAssemblyとは何か、なぜそれが重要なテクノロジーであるのか、現在はどのような分野で利用されているかを説明します。また、WebAssemblyが大きな影響をもたらす可能性がある用途や、WebAssemblyの将来に関する予測も紹介します。 WebAssemblyとは何か WebAssembly（Wasm）とは、さまざまなプログラミング言語と多様な実行環境の間に位置する中間層です。30以上の異なるプログラミング言語で書かれたコードを.wasmファイルにコンパイルし、そのファイルをブラウザ、サーバ、あるいは自動車でも実行できます。 「WebAss
うれしいことに、builder.ioのホームページは今やモバイル端末でもPageSpeed Insightsで100点中100点をとれるようになりました。 これはQwikを導入したおかげです。 Qwikはアプリケーションの規模に関係なく高いパフォーマンスを実現します。 上記のスコアは、以下の優れた技術によって達成されました。 Qwikで提供されるページの起動に必要なJavaScriptは1KB未満 ホームページは画面上の領域のコンテンツに必要なHTMLのみを送信 Partytownを利用し、すべてのサードパーティスクリプトをWeb Workerに移動 builder.ioの視覚的なノーコードエディタを利用してサイトを作成 Qwikは、数百のコンポーネントや数MBのコンテンツを有する大規模なサイトでも高速なパフォーマンスを実現します。 また、クライアントコンポーネントに移動できるインタラクテ
最近のバンドラは、アプリケーションコードのどの部分をいつ遅延読み込みするかを開発者が決めなければなりません。 開発者は以下のように、コードベースにdynamic importを挿入することによって、遅延読み込みをする場所とタイミングを決定します。 async function doSomething() { const chunk = await import('./my-chunk'); console.log(chunk.someSymbol); } 開発者は以下を行う必要があります。 コードのどの部分が遅延読み込みに適しているかを判断します。 既存のアプリケーションワークフローとの互換性がある方法で遅延読み込みを実行します（遅延読み込みは本質的に非同期ですが、遅延読み込みを実行するための理想的な関数は同期型の可能性があるため、遅延読み込みコードを設置できる場所は限られます）。 ./m
古川陽介 株式会社リクルート プロダクト統括本部 プロダクト開発統括室 グループマネジャー 株式会社ニジボックス デベロップメント室 室長 Node.js 日本ユーザーグループ代表 複合機メーカー、ゲーム会社を経て、2016年に株式会社リクルートテクノロジーズ(現リクルート)入社。 現在はAPソリューショングループのマネジャーとしてアプリ基盤の改善や運用、各種開発支援ツールの開発、またテックリードとしてエンジニアチームの支援や育成までを担う。 2019年より株式会社ニジボックスを兼務し、室長としてエンジニア育成基盤の設計、技術指南も遂行。 Node.js 日本ユーザーグループの代表を務め、Node学園祭などを主宰。Twitter: @yosuke_furukawaGithub: yosuke-furukawa
Qwikは、JavaScriptの読み込みと実行を可能な限り遅延させ、ユーザのアクションがあった場合のみ実施することで、読み込みを最も高速化することを目指しています。 この処理は初回の読み込み時だけでなく、アプリケーションが続く限り行われます。 言い換えると、Qwikはきめ細かい遅延読み込みを追求しているのです。 「きめ細かい」とは、ユーザのアクションを処理するのに直接必要なコードのみがダウンロードされるという意味です。 この記事では、きめ細かい遅延読み込みを実現するために解決すべき技術的課題について探っていきます。 リスナーをシリアライズ 最も明確に解決すべき課題は初回のページ読み込みです。 この点に関しては、「HTMLを最初に、JavaScriptを最後に」で対応策をすでに取り上げました。 ポイントは、イベントの名称とアクションをURLとしてシリアライズし、DOMの属性として保持するこ
すべてのフレームワークはステートを保持する必要があります。フレームワークはテンプレートを実行することでステートを構築します。ほとんどのフレームワークは、このステートをリファレンスやクロージャとしてJavaScriptヒープに保持します。Qwikのユニークな点は、ステートが属性としてDOMに保持されることです（リファレンスもクロージャもシリアライズして送受信するのは不可能ですが、文字列であるDOM属性なら可能です。これがresumability(再開性）のカギとなります）。 DOMにステートを保持することには、以下のように多くのユニークなメリットがあります。 DOMはシリアライズの形式としてHTMLを使用します。ステートを文字列属性としてDOMに保持することで、アプリケーションをいつでもHTMLにシリアライズできます。HTMLを送信し、別のクライアントでDOMにデシリアライズすることが可能に
世界中にQwikを紹介した前回の記事では、 多くの要素についてざっと触れるに留まり、詳細については後で説明するとお約束していました。 Qwikとその背景にある設計思想を知る前に、まず私たち（業界）が現在の場所までどのようにたどり着いたかを理解しておくことが重要です。 現代のフレームワークはある前提のもとに成り立っており、 それが優れたTime to Interactive（TTI）スコアの実現を妨げているのですが、 その前提とはどのようなものなのでしょうか。 現行世代のフレームワークの現時点における限界を理解することで、 Qwikの設計思想がなぜ最初は驚くべきものに思えるのか、より深く知ることができるでしょう。 TTIについて TTIは、URLに遷移してからページがインタラクティブになるまでの時間を測定したものです。 レスポンシブなサイトとしての体裁を整えるには、サーバーサイドレンダリング
Builder.ioは、強力なビジュアルエディタにより、開発者ではない人が超高速なサイトを開発・編集できるようにしています。 私たちのビジュアルエディタが優れている点の1つは、AngularからWeb Components、 そしてその間にあるすべてのフレームワークに至るまで、 さまざまなツールで同じサイトを生成できることです。 出力されるコードは速度が最適化されています。 私たちのツールで作成されたサイトは、手作業で作成されたサイトの大部分よりも高速です。 私たちはこれを心から誇りに思っています。 私たちの製品は、スピードがとても重要であるeコマースに焦点を当てています。 優れたTime to Interactiveの実現は困難 どんなにコードが最適化されていても、静的HTMLのみを提供していない限り、 eコマースサイトがPageSpeed Insightsで100点中100点のスコアを
初めて会社を起業する人のほとんどは、集団をマネジメントする方法を学ぶ間に、創業当初の従業員を燃え尽き症候群にさせてしまうと思います。 筆者のアドバイスがそのようなケースを減らせるなら、ここに書いておく価値があるでしょう。 筆者は小規模なチームやスタートアップ企業のマネージャーのためにこの記事を書きました。 ほとんどのアドバイスは、大規模な企業のマネジメントには当てはまらないのではないかと思います。 なお、急成長している企業に入社する人への全般的なアドバイスについてはこちらをご覧ください。 筆者について 中・小規模のエンジニアリングチームを数チーム管理した経験あり On DeckのCTO CoinListの元エンジニアリング担当VP AngelListの元リモート責任者 Product Huntの元CTO それでは始めましょう。 マネージャーはすべての失敗に責任を負う 分かります……とても前
POSTD読者の皆さんはじめまして、本メディアでキュレーターを担当させていただいている古川陽介と申します。 株式会社ニジボックスでデベロップメント室室長を務める他、株式会社リクルートでプロダクト開発部署のマネージャーも兼務しています。 また、Japan Node.js Associationの代表理事として、Node.js の普及を目指す活動なども行っています。 私が普段の仕事や活動の中で強く感じているのは、フロントエンドエンジニアの役割が大きな変換点を迎えているということです。 端的に表現するとスマートフォンの登場をきっかけとしたデバイスの多様化によって、フロントエンドエンジニアの領域が拡大したと言うことになると思います。 パフォーマンスや開発の生産性を著しく上昇させる、ReactやVueを駆使したモダンフロントエンド開発と、それを実現するための組織構築は、今後のサービスやプロダクト開発
一般ユーザー向けの大規模なWebサイトや、モダンWeb上で動作するWebアプリケーションを運営する場合、CDNなどのキャッシングサービスによって静的コンテンツをキャッシュすることが極めて重要です。 しかしこうしたサービスは、非常に複雑で分かりにくいものです。 幸い、IETF（Internet Engineering Task Force）のHTTPワーキンググループがこの状況を改善すべく、HTTPの新標準策定に取り組んでいます。 最近、同ワーキンググループでは、キャッシングのデバッグとキャッシュ設定の管理を容易にすることを目的とした、HTTPヘッダに関する2つの新標準案の発表に向けて活発な動きがありました。 このことが何を意味し、どのように機能するのか、そしてWeb制作に携わる開発者全てがなぜ注目すべきなのかについて見ていきます。 新標準 この記事で取り上げる標準案は以下の2つです。 Ca
次のページ
このページを最初にブックマークしてみませんか？
『POSTD | ニジボックスが運営するエンジニアに向けたキュレーションメディア』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
