String#replaceAll moved to the stable ES, per June TC39 meeting Promise.any and AggregateError moved to the stable ES, per July TC39 meeting Added Reflect[@@toStringTag], per July TC39 meeting Forced replacement of Array#{ reduce, reduceRight } in Chrome 80-82 because of a bug, #766 Following the changes in the upsert proposal, { Map, WeakMap }#emplace replace { Map, WeakMap }#upsert, these obsole
Edit: The project still is alive, some other contributors like @slowcheetah have permissions for the project to keep going, see #767 (comment) 👍 Full summary of project governance here #767 (comment) 👍 Looks like @zloirock the author and main maintainer of the project will be will be unavailable for some time 1.5 years. Sources: #767 (comment), #757 (comment), #747 (comment), #548 (comment) What
The globalThis proposal introduces a unified mechanism to access the global this in any JavaScript environment. It sounds like a simple thing to polyfill, but it turns out it’s pretty hard to get right. I didn’t even think it was possible until Toon blew my mind with an unexpected, creative solution. This write-up describes the difficulties with writing a proper globalThis polyfill. Such a polyfil
ungap Modern Web development one jump at the time Photo by Denny Luan on Unsplash About The ungap project was born after years of attempts to always fix the same issue, but never in a modular way and, most importantly, never in a single, 100% code covered, organization. Focused on size, compatibility, and quality Each module is written in ES5 compatible syntax to avoid both unnecessary transpilers
The whatwg-fetch package is now a module with exports. The following methods/classes are available: fetch Headers Request Response DOMException All exports except for DOMException represent the polyfill implementations, not the native variants if they are available. This library still automatically acts like a polyfill if native window.fetch is unavailable; there is currently no way to use it as a
See all changes in #325 Well-known symbols definition extracted from es.symbol module for loading only required features, for example, in MS Edge Added compositeKey and compositeSymbol methods (stage 1 proposal) Updated String#codePoints proposal per tc39/proposal-string-prototype-codepoints@673b43e Updated .name properties of String#{trimStart, trimEnd , trimLeft, trimRight} New collections metho
JavaScriptを書くにあたって、未だにブラウザによっては存在しない機能を考慮せざるを得ない状況が続いています。そこで取る対策として、PolyfillとPonyfillがあります。 気の抜けない、ブラウザごとの差 最近でこそブラウザは強制バージョンアップするものが増えてきましたが、もはやバージョンアップすることのないIE 11、そしてOSとセットでしかアップデートできないiOSのSafariなど、常に最新といかない環境も残り続けています。さらに言えば、JavaScript自体もECMA 201xというように、毎年バージョンアップし続けるので、ブラウザごとにそれをキャッチアップできるタイミングも違ってきます。 ということで、どこまで行っても「ブラウザごとの実装差」は残り続けることとなってしまいます。 Polyfillのメリットと欠点 Polyfillとは、「標準となったメソッドが存在しな
Intro W3C の TAG から、主にブラウザ API の Polyfill に関するドキュメントが公開された。 Polyfills and the evolution of the Web Polyfill は便利な一方で、時として標準化の妨げになってしまう場合があるため、それを避けるために、Polyfill 実装者、利用者、仕様策定者などが、どう振る舞うべきかという趣旨である。 今回はこの内容を元に、Web の進化と協調する Polyfill のあり方について、主に「実装者」がどうすべきかに着目し記す。 Web における Breaking Change Breaking Change は、簡単に言えば 後方互換を失うことで既存のものが壊れる可能性がある変更 のことを表す。 そして、Web における Breaking Change (Break the Web)、具体的には Web
Polyfills are a valuable part of Web architecture, because they promote the adoption of new features during the implementation process. However, polyfills can also create problems for standardization efforts and therefore for the future of the Web. This document defines the risks, benefits, and role of polyfills on the Web, and proposes best practices for implementors, spec editors, website develo
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く