この記事では、ReactにおいてDOMへのアクセスが必要な理由と、その際にRefがどう役立つのかを見ていきます。また、useRef、forwardRef、useImperativeHandleという3つのフックについて説明し、これらを適切に使用する方法を紹介したいと思います。 この記事と同じ内容を扱ったYouTube動画も公開していますので、活字媒体よりも動画視聴を好まれる方はそちらをご覧ください。文字ではなく、アニメーションと音声で同じ概念を解説しています。 この記事は動画形式でも公開しています。 目次 useRefを使用してReactでDOMにアクセスする 親から子にRefをpropとして渡す forwardRefを使用して親から子にRefを渡す useImperativeHandleを使用した命令型API useImperativeHandleを使用しない命令型API Reactには

目次＃ 前編 準備段階：計画と指標 パフォーマンスを重視する文化、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モジュール、モジュール/ノーモジュールのパターン、ツリーシェイ

目次＃ 前編 準備段階：計画と指標 パフォーマンスを重視する文化、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モジュール、モジュール/ノーモジュールのパターン、ツリーシェイ

写真： Jr Korpa on Unsplash Intro：2021年はこれまでCSSにとって盛りだくさんな一年でした。 CSSワーキンググループはCSSの仕様にさまざまな変更を加え、既存機能を改良するとともに多くの新機能を追加しました。 一部のブラウザには、すでに実験的に実装されているものもあります。 ブラウザベンダーは、新機能のサポートだけでなく、開発者を悩ませるブラウザの互換性に関する5大問題（#compat2021）の解決にも注力しています。 2021年もそろそろ終わりに近づいているので、今回は2022年に実装されそうなCSS機能を紹介したいと思います。 (※訳注：翻訳元の記事は2021年12月27日公開) 目次 はじめに 注目の新機能（クロスブラウザ対応） コンテナクエリ カスケードレイヤー カラー関数 新しいビューポート単位 :has()擬似クラス overscroll-be

うれしいことに、builder.ioのホームページは今やモバイル端末でもPageSpeed Insightsで100点中100点をとれるようになりました。 これはQwikを導入したおかげです。 Qwikはアプリケーションの規模に関係なく高いパフォーマンスを実現します。 上記のスコアは、以下の優れた技術によって達成されました。 Qwikで提供されるページの起動に必要なJavaScriptは1KB未満 ホームページは画面上の領域のコンテンツに必要なHTMLのみを送信 Partytownを利用し、すべてのサードパーティスクリプトをWeb Workerに移動 builder.ioの視覚的なノーコードエディタを利用してサイトを作成 Qwikは、数百のコンポーネントや数MBのコンテンツを有する大規模なサイトでも高速なパフォーマンスを実現します。 また、クライアントコンポーネントに移動できるインタラクテ

WebAssemblyは今、転換点にあります。今後数年間で、コンテナ化からプラグインシステムやサーバレス・コンピューティング・プラットフォームに至るまで、IT業界全体でWebAssemblyの導入が増えると筆者は予想しています。この記事では、WebAssemblyとは何か、なぜそれが重要なテクノロジーであるのか、現在はどのような分野で利用されているかを説明します。また、WebAssemblyが大きな影響をもたらす可能性がある用途や、WebAssemblyの将来に関する予測も紹介します。 WebAssemblyとは何か WebAssembly（Wasm）とは、さまざまなプログラミング言語と多様な実行環境の間に位置する中間層です。30以上の異なるプログラミング言語で書かれたコードを.wasmファイルにコンパイルし、そのファイルをブラウザ、サーバ、あるいは自動車でも実行できます。 「WebAss

すべてのフレームワークはステートを保持する必要があります。フレームワークはテンプレートを実行することでステートを構築します。ほとんどのフレームワークは、このステートをリファレンスやクロージャとして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

React Server Components（RSC）は、ページの読み込みパフォーマンスやバンドルサイズのほか、Reactアプリケーションの書き方に近い将来大きな影響を与えることになる、素晴らしい新機能です。 Plasmicでは、Reactのビジュアルビルダーを開発しており、Reactのパフォーマンスには大きな関心を持もっています。 当社のクライアントの多くは、Plasmicを使用して高いパフォーマンスが求められるマーケティングサイトやECサイトを構築しています。 したがって、RSCはまだReact 18の初期実験機能ですが、Plasmicではその仕組みを詳しく調べています。 このブログ記事では、これまでに分かったことを紹介したいと思います。 Plasmicのメンバーによるツイートまとめもご覧ください。 React Server Componentsとは何か サーバサイドレンダリングとの

筆者はTypeScript型チェッカーtscをRustではなく、Goに移植しようと思います。拡張可能なRustプラットフォームSWCの作者の発言としては、奇妙に聞こえるかもしれません。理由を説明したいと思います。 なぜtscを移植するのか TypeScriptの普及が進むにつれて、大規模プロジェクトではあるジレンマに直面しています。型チェックは、ワークフローの中で最も時間がかかるプロセスの一つになっているのです。開発者は、イテレーションのサイクルを遅らせることなく、型安全を保証することを望んでいます。 tsc（TypeScript Compiler）は、型の妥当性をチェックし、コードをJavaScriptにコンパイルします。コードの量が多いほど、コンパイルには時間がかかります。中規模から大規模のTypeScriptプロジェクトでは、このコンパイルに膨大な時間がかかります。開発者はワークフロ

クイックサマリー ‐ 国際化ルーティングは、厳密にはNext.jsの新機能ではありません。（v.10以降搭載されています。）この記事では、この機能のメリットだけではなく、こうした機能を利用して最高のユーザ体験と円滑な開発者体験を実現する方法についても見ていきます。自己文書化コードやバンドルサイズの削減、さらにはランタイムエラーではなくコンパイル時エラーに興味のある方は、是非このまま読み進めてください。 開発中のアプリにおいて、ロケール（または国、あるいは両方）ごとにルートを設定したい場合、Next.jsで簡単に対応できるようになりました。プロジェクトのrootディレクトリにnext.config.jsがない場合、新たに作成してください。このスニペットからコピーしても構いません。 /** @type {import('next').NextConfig} */ module.exports

あなたが知らない既存機能があるかもしれません！ マイクロソフト社は2006年、Microsoft Officeの新バージョンで追加してほしい機能について、顧客調査を実施しました。驚いたことに、ユーザが希望した機能の90%以上はすでに実装されており、その存在が知られていないだけであることが判明しました。機能の「見つけにくさ」の問題の解決策として同社が考案したのが、現在のMicrosoft Office製品でおなじみの「リボンUI」です。 この問題はOfficeに限ったものではありません。日々使用するツールの機能をすべて把握している人はほとんどいません。PostgreSQLのように大規模なツールであればなおさらです。数週間前にPostgreSQL 14がリリースされたばかりなので、この機会にPostgreSQLのあまり知られていない機能に注目してみたいと思います。 この記事では、Postgre

私は先日、開発者が何を最も大きな課題に挙げているかを知ることで、開発者コミュニティのニーズを理解できるという記事を書きました。 元々の投稿はMDN Developer Needs Assessment（2019年）の結果を要約したものでしたが、不運なことに、この調査は2020年に中止されました。この調査情報は、Webプラットフォーム全体の方向性を定めるのに役立つ点で、私たちのチームにとって重要だったため、調査の中止は残念なことです。 調査を実施していたMozillaの代わりとして、私はチームのために、開発者の大まかなニーズを把握する調査を企画しました。 3カ月ごとに、米国、英国、インドのWeb開発者やWeb開発における意思決定者約700人をランダムにサンプリングして実施し、過去に実施したすべての調査とデータを比較して、トレンドに変化があるかを見ていきます。 注意すべきなのは、MDN Sur

Core Web Vitals（CWV）は2020年5月に発表されました。Googleはこの発表の中で、「より良いWebのためにページエクスペリエンスを評価する」と述べています。特に重要なのは、この評価がGoogleの検索順位アルゴリズムの一部を構成することでした。つまり、高速なWebサイトは、同等の遅いWebサイトよりも順位が上になり、Google検索によるトラフィック（ほとんどのWebサイトにとってWebトラフィックの最も大きな部分を占める）が増えます。 Webパフォーマンスコミュニティは、Webパフォーマンスのビジネス上のメリットを売り込むことに関して、常にSEO業界に劣っていました。Webパフォーマンスがビジネスのパフォーマンスに直接影響を及ぼす証拠が数多く存在するにもかかわらずです。しかし、今やSEO業界全体がWebパフォーマンスを重視するようになり、企業もWebパフォーマンスに

Rustコードのコンパイルが遅いことは誰でも知っています。しかし筆者は、世の中のほとんどのRustコードはコンパイルをもっと速くできると強く感じています。 例えば、つい最近の記事にこのように書かれていました。 一方、Rustでは、プロジェクトやCIサーバーの性能にもよりますが、 CIパイプラインの実行に15～45分かかります。 これは筆者には理解できません。GitHub Actions上にあるrust-analyzerのCIの所要時間は8分です。しかも、これは100万行の依存関係に加え、20万行の独自コードが記述されたとても大規模で複雑なプロジェクトでの話です。 確かに、Rustは根本的な部分で非常にコンパイルが遅いのは間違いありません。Rustはジェネリクスのジレンマにおいて「遅いコンパイラ」を選び、全体的な設計思想としてコンパイル時間よりもランタイムを優先しています（この点に関する優れ

名前が1文字の「-」という謎めいたnpmパッケージは、2020年にレジストリで公開されて以来、70万回以上ダウンロードされています。 さらに、このパッケージには有効なコードが含まれていません。では、一体なぜこれほど多くダウンロードされているのでしょうか？ npmパッケージ「-」の中身 「-」というnpmパッケージは、2020年初めにnpmレジストリで公開されてから、約72万回もダウンロードされてきました。 パッケージのバージョンは0.0.1のみで、ファイルは3つです。 tar tvf 0.0.1/--0.0.1.tgz package/dist/index.js package/package.json package/README.md これらのファイルは主にマニフェスト（package.json）とindex.jsで、特に面白い点はなく、スケルトンコードが書かれているだけです。 マニフ