Webブラウザの進化に伴い、新しい機能や技術が次々と登場しています。しかし、各ブラウザの実装状況や互換性を把握することは、開発者にとって大きな課題でした。この課題を解決するため、2024年に整備が進み、2025年から本格的に活用できる指標が「Baseline」です。本記事では、2024年に大きく進展したBaselineとWeb Platform Status Dashboardについて紹介します。 Baselineのおさらい Safari、Chrome、Edge、Firefoxといった主要なWebブラウザ間での機能の互換性レベルを体系的に定義し、開発者に明確な指標を提供するものです。これにより、クロスブラウザ開発における予測可能性と信頼性が向上します。 開発者向けの主要なリファレンスプラットフォームであるMDNやCan I Useにおいて、各機能のBaselineステータスがラベルとして明
3行まとめ pnpm の --filter オプションにはパッケージ名だけでなく git の commit や branch も渡すことができる pnpm ls --filter をうまく使えば「main branch からの diff の影響を受けるパッケージ」の一覧を取り出せる ドキュメントや help をちゃんと見ると、意外と知らないことが書いてある モチベーション LayerX のバクラク事業部では Webapp（Web Frontend アプリケーション）のモノレポ化を進めており、1つのリポジトリに複数の Next.js アプリケーションが存在します。 そこで悩ましいのが CI でのテストなどの実行です。 そのまま全件実行すると時間が長くなっていく e.g. アプリAのコードしか変更してないのに、アプリBのテストも実行されてしまうと時間もお金も無駄にかかる 何もしないとプロダクト
Interop 2025の取り組みがスタートした旨を知らせる記事が、参加組織それぞれから一斉に公開されました。 Announcing Interop 2025 | WebKit Interop 2025 Launch - Bocoup Interop 2025: another year of web platform improvements | Blog | web.dev Interop 2025 | Igalia Microsoft Edge and Interop 2025 - Microsoft Edge Blog Launching Interop 2025 - Mozilla Hacks - the Web developer blog 2025年の重点分野とその進捗状況はInterop 2025 Dashboardで確認ができます。 Interop 2024より引き継がれ
Published: February 7, 2025 In April 2024, a post on this site announced that the Popover API was Baseline Newly available. However, we got it wrong, and popover enters Baseline as of January 27, 2025. This post explains why we got it wrong, and what has changed since to make these mistakes less likely to happen. What's the Popover API? The Popover API provides a built-in way to create various typ
Back in July of 2024 we announced our plan to make ESLint a more general-purpose linter that is capable of linting any language. In October 2024, we announced linting support for JSON and Markdown, delivering on that vision. Today, we’re excited to add to the list of supported languages with the introduction of CSS support. CSS linting with @eslint/css CSS linting is accomplished using the @eslint
この記事では、noteがリリースされた2014年当初から現在までのフロントエンド技術の移り変わりをざっくりと振り返ります。 Angular 1.x 系からスタートしたnoteは、その後Nuxt.jsへの移行、さらにはNext.js + Svelteを活用したリアーキテクチャの道を歩んできました。 フロントエンド領域がめまぐるしく変化する中で、なぜこれらの選択をしてきたのか、どんな課題があったのかなどをまとめました。 ※ この記事で扱う内容は、2014年〜2025年1月時点での内容です Angular 1.x系でnoteをリリースした背景2014年当初の状況noteがリリースされた2014年は、フロントエンドフレームワークがまだ混沌としていた時代でした。Reactは登場していたものの、企業での採用実績やノウハウがそこまで多くはなく、Vue.jsはまだ黎明期。AngularJS（Angular
[[toc]] Three years ago, I wrote a post about shipping ESM & CJS in a single package, advocating for dual CJS/ESM formats to ease user migration and trying to make the best of both worlds. Back then, I didn't fully agree with aggressively shipping ESM-only, as I considered the ecosystem wasn't ready, especially since the push was mostly from low-level libraries. Over time, as tools and the ecosyst
TypeScript’s satisfies operator lets us check the type of a value (mostly) without influencing it. In this blog post, we examine how exactly it works and where it’s useful. Notation used in this blog post # For showing computed and inferred types in source code, I use the npm package asserttt – e.g.: // Types of values assertType<string>('abc'); assertType<number>(123); // Equality of types type
Promise と Thenable Promise が ECMAScript の言語仕様に追加されたのは ES2015 ですが, Promise ライクなオブジェクトはそれ以前からも広く使われてきました (jQuery の Deferred など). そういった Promise ライクなオブジェクトとの互換性のため, Promise の仕様は本物の Promise と Promise ライクなオブジェクトを混ぜて使えるようになっています. 具体的には, Promise ライクなオブジェクトは一般に Thenable という共通のインターフェースを持つことになっています. オブジェクトが Thenable であるために必要なのは「then() という名前のメソッドを持っている」という一点のみです. もし Promise を解決 (resolve) するときに使われた値が Thenable
Tree views are a core part of the GitHub experience. You’ve encountered one if you’ve ever navigated through a repository’s file structure or reviewed a pull request. On GitHub, a tree view is the list of folders and the files they contain. It is analogous to the directory structure your operating system uses as a way of organizing things. Tree views are notoriously difficult to implement in an ac
乗りこなせ！ モダンフロントエンド Container Queries/祖先要素に応じたCSSの切り替え ［CSS Modern Features no.2］ こんにちは！サイボウズ フロントエンドエキスパートチームの麦島です。 今回のテーマはContainer Queriesです。 Container Queriesは、祖先要素として存在するコンテナのスタイルに応じてCSSを適用するための機能です。利用時は@containerで宣言します。 従来でもメディアクエリでブラウザのビューポート幅などに応じたCSS適用は可能でしたが、あくまでもブラウザやウィンドウ全体のスタイルに依存するものでした。Container Queriesでは画面の特定の範囲を「コンテナ」として定義し、コンテナのスタイルに応じたCSSを適用できる点が、従来の手法との大きな違いとなります。 Container Queri
CSS の新しい機能疑似クラス セレクタ :is() および :where() コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 CSS を記述するときに、同じスタイルルールで複数の要素をターゲットとする長いセレクタリストになることがあります。たとえば、ヘッダー要素内に見つかった <b> タグの色を調整するには、次のように記述します。 h1 > b, h2 > b, h3 > b, h4 > b, h5 > b, h6 > b { color: hotpink; } 代わりに、:is() を使用して、長いセレクタを回避しながら読みやすさを向上させることができます。 :is(h1,h2,h3,h4,h5,h6) > b { color: hotpink; } 読みやすさとセレクタの短縮は、:is() と :where() が CSS にもたらす価値のほんの一部
Accessibility essentials every front-end developer should know Many developers view accessibility as an overwhelming task, requiring a lot of extra effort or specialized knowledge. But a few basic practices can make a significant impact. In this article, I'll walk you through the key accessibility principles I believe every front-end developer should apply when building components, including: Sema
はじめに 型安全性と拡張性の両立 宣言マージの活用 宣言マージとは？ 宣言マージを使ってメッセージの型を拡張する 型エイリアスと Generics を使った方法との比較 宣言マージを使うことで実装と型の整合性を担保しやすくなる MUI での宣言マージの活用事例 注意点 VS Code 上の型チェックの表示が tsc の型チェックの結果と異なる場合がある ライブラリ側が空の interface のままだと困ることがある なぜ react-redux ではこのアプローチをやめたのか？ まとめ interface の宣言マージを活用することで はじめに こんにちは！Element チームでフロントエンドを担当している all-user です。 Elementチームとは、テックタッチのプロダクト開発の中でも主にDOMとのインタラクション周りの開発を担当しているチームで、Shadow DOM や i
「なにがしたいか」をベースにコメントをつけておくと、後で読むときのコストが下がりやすい。 実際にプロダクトコードで書いたことがあるコメント↓ (簡略化してます) // 画面内に入った動画を自動再生する+ほかの動画は停止する (すでに再生済みだったら再生しない) useEffect(() => { if (inView && !hasBeenPlayed && canAutoplay) { /* ... */ pauseOtherVideo(); play(); } /* ... */ }); このコンポーネントにはコレを含めて4つのコメント付きのuseEffectがあった。たびたび読み返す機会があったが、その度にこれらのコメントが大いに役立った。 なぜコメントが必要なのか? useEffectの中身はたいてい複雑な処理になる。しかもたいてい無名関数を渡すので、実現したい仕様に関する情報がな
こんにちは、フロントエンドエンジニアのやなぎ（@apple_yagi）です。 PR TIMESではフロントエンドのReactリプレイス当初より Barrel file を作成するルールがありました。しかし、先日そのルールを廃止することに決めたため、その経緯についてご紹介します。 Barrel filesとは Barrel filesとは複数のモジュールを1つのファイル（Barrel file）にまとめてexportすることを指します。以下の例ではutils/test.ts 、utils/fuga.ts 、utils/hoge.ts で export されている定数を utils/index.ts で再exportしています。 // utils/test.ts export const test = 1; // utils/fuga.ts export const fuga = 2; //
無垢な仔猫の写真を集めたウェブサイトを訪問したと想像してみてください。かわいい仔猫達の写真の背後には、このウェブサイトの強大な力が隠れています。誰かがウェブサイトにアクセスすると、サイトのオーナーはその訪問者のネット上の行動に関するあらゆる情報を入手できます。その中には、銀行取引情報、SNS上の投稿やメッセージ、メール、オンラインの購買データなどが含まれます。あなたが受ける信用面や金銭面の損害はどれほどのものになるでしょうか。あなたのメッセージが流出し、銀行口座のお金が使い込まれるかもしれません。しかし幸いなことに、実際にはそのような状況は起こりません。それは、SOPとCORSのお陰なのです。 目次 Ajax（Asynchronous JavaScript And XML） インターネットがジャングルではない理由 認証情報を「含める」vs「含めない」 CORSルールの定義 クロスオリジンリ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
