GitHubで最もホットなライブラリをランキング表示してくれるbestofjs.orgというサイトがあります。
そしてここは毎年、その一年で最もホットだったライブラリを発表しています。

選考基準は『その年増えたスターの数』であり、恣意的要素の入る余地はありません。
ちなみに2016年の総合ランキング1位はVue.js、2017年の総合ランキング1位はVue.js、2018年の総合ランキング1位はVue.jsです。

以下は2019年のランキング、2019 JavaScript Rising Starsの日本語訳です。

JavaScript ライジングスター 2019

4回目のJavaScript ライジングスターにようこそ！

2019年にGitHubで最も注目を集めたプロジェクトを、数字で見てみましょう。

以下のチャートは、2019年の一年間にGitHubで増加したスターの数を比較したものです。Webプラットフォームに関するベストプロジェクトを集めたリストであるBest of JavaScriptからの分析となります。各プロジェクトをクリックすると、プロジェクトの詳細を閲覧することができます。

総合ランキング

1位： Vue.js
2位： VS Code
3位： React
4位： Vue Element Admin
5位： Svelte
6位： Axios
7位： Ant Design
8位： TypeScript
9位： Puppeteer
10位： Create React App

4年連続でVue.jsが総合優勝を飾り、2019年にも30000以上のスターを稼ぎ出しました。

次いでReactとVSCodeが、昨年と同じように続いています。

総合ランキングで最大の伸びを示したのがVue Element Adminでした。
これは、Vue.jsコンポーネントを使った優れたダッシュボードを構築することができるソリューションで、堂々の4位を取得しました。

Svelteは数年前から存在するプロジェクトですが、2019年ついに飛翔し5位に入りました。

TypeScriptがベストテン入りし、この成功は過去数年のJavaScriptの変化の集大成のひとつです。

Node.jsの作者が新たに作ったJavaScriptランタイムDenoは、2018年に新登場しました。
これは13位で、まだトレンドに入っています。

フロントエンド フレームワーク

1位： Vue.js +31.4k
2位： React +22.9k
3位： Svelte +20.0k
4位： Angular +12.0k
5位： Omi +3.8k

2019年はSvelteが躍進してAngularを追い抜き、
Vue.jsとReactの背後を突く3位に上昇しました。

これはBIG-3がBIG-4になったことを意味するのでしょうか？

Svelteは他のフレームワークと大きく異なっていて、実際にはフレームワークではなく、ビルド時に全てを構築するコンパイラのようなものです。

ReactやVue同様に、データが変更されたときに画面を更新するアプリを開発者は書くことができます。
ただし最大の違いとして、そのフレームワークがブラウザ上で実行されるのではなく、ビルド時に実行されます。
コンパイラは、開発者が作成したコンポーネントを、DOMを直接操作する命令型コードに変換します。
そのため、ブラウザに渡されるコードは小さくなり、非常に高速に実行されます。
たとえば組み込みデバイス向けのアプリケーションなどに適しているでしょう。

そのパフォーマンスに加えて、ややこしいCSSトランジションも簡単に制御することができます。

バージョン3ではリアクティブな仕組みも強化されています。
UIをトリガーするだけで、変数までも更新してくれます。

SvelteがこれまでのBIG-3と同じくらい成功すると断定するには時期尚早ですが、2020年はこれをフォローしておく価値があるでしょう。

Node.js フレームワーク

1位： Nest +11.5k
2位： Next.js +10.6k
3位： Strapi +10.2k
4位： Nuxt +7.4k
5位： Express +5.1k

Node.jsに新たなチャンピオン、Nestが誕生しました。
NestはAngularから多くの概念を取り入れた、フルスタックのフレームワークです。

2018年の勝者であったNext.jsは、その席こそ譲ったものの堂々の2位です。
フロントエンドをReactで、バックエンドをNode.jsで構築する際に最適なソリューションのひとつです。

3位に入ったStrapiはオープンソースのヘッドレスCMSで、APIエンドポイントを迅速に生成・管理することができます。
『4コマンドで始めよう』
APIエンドポイントはRESTもしくはGraphQLに対応しています。

4位はNuxtで、フロントエンドにVue.jsを使うときに最適なフルスタックフレームワークです。
サーバサイドレンダリング、クライアントサイド、あるいは静的のみといった様々な戦略に対応しています。

ExpressはNode.jsのための古びたフレームワークですが、まだトップ5に残っています。
巨大なエコシステムが存在し、多くのNode.js開発者には馴染みがあることでしょうが、最後のコミットから既に半年以上が経過していることに注意が必要です。
時代は変わっていますか？

React エコシステム

1位： Ant Design +14.6k
2位： Create React App +13.5k
3位： Gatsby +11.5k
4位： Next.js +10.6k
5位： Material UI +10.2k

1位にAnt Design、5位にMaterial UIと、React用のコンポーネントとヴィジェットが入賞しました。

2位のCreate React Appは、Reactアプリを新しく始める際の、事実上のデファクトスタンダードです。
今年の目玉として、TypeScriptがサポートされました。

今年のReact世界で最大の変更点は、フックの導入です。

Reactはビューレイヤだけしか提供しないので、コンポーネント間でロジックを共有する方法は常に議論の的になっています。
その進化は概ね4ステップに分けられます。
・2013年：Mixin
・2015年：高階コンポーネント
・2017年：Render Propsパターン
・2019年：Hooks

今年は、フックの力を使うことで問題を解決したライブラリが多数現れました。
・Redux
・React Router
・React Hook Form

Hooksで進化の最終段階に到達しましたか？

Vue エコシステム

1位： Vue Element Admin +22.7k
2位： Element +9.4k
3位： Vuetify +7.5k
4位： Nuxt +7.4k
5位： vue-cli +5.8k

2連覇したVue Element Adminは、Elementを使って美しいダッシュボードを構築するVue.jsコンポーネントです。

2位のElementは、多くのコンポーネントを持つUIライブラリです。

マテリアルコンポーネントフレームワークであるVuetifyは、7月にバージョン2がリリースされ急上昇してランクインしました。

NuxtはVue.jsアプリケーションを構築するWebフレームワークであり、3年連続でランクインしています。

5位には、強力なGUIを備えプロジェクトの立ち上げを加速するオフィシャルのツールキット、vue-cliが入りました。

Angular エコシステム

1位：ngx-admin +4.8k
2位：Material Design for Angular +2.4k
3位：Angular CLI +2.1k
4位：NG-ZORRO +1.7k
5位：NgRx +1.3k

Angularプロジェクトで最も人気であるngx-adminは、管理ダッシュボードを構築するためのテンプレートを提供します。

2位のMaterial Design for AngularはAngular CDKと似たような、マテリアルデザインのAngular公式コンポーネントです。

ReactやVueと同様に、デザインコンポーネントであるNG-ZORROが4位に入りました。

Angularは2019年5月にバージョン8のメジャーリリースが行われました。
新機能のひとつとして、Angular CLIはモダン向けとレガシー向けにバンドルを分けることによってバンドルサイズを20%減少させることに成功しました。
また既存のCLIコマンドを変更したり新たなコマンド追加したりできる、新たなBuilders APIも存在します。

Angularのバージョン9もRCとなっていて、2020年の前半にリリースされる見込みです。
バージョン9の主な変更点はIvyと呼ばれる新しいコンパイラで、構築時間の短縮及びバンドルサイズの減少が期待されています。

テスト

1位：Puppeteer +13.9k
2位：Cypress +7.8k
3位：Jest +6.5k
4位：React Testing Library +5.7k
5位：Puppeteer Recorder +2.2k

今年は、カテゴリをテストフレームワークに限定するのではなく、E2Eテストやブラウザ自動化ツールなども対象としました。

Puppeteerは非常に人気のあるヘッドレスChrome制御ツールです。
Webスクレイピングやスナップショット撮影など多くのユースケースがあります。
ChromeエクステンションのPuppeteer Recorderも5位にランクインしています。

CypressはE2Eテストを行うためのソリューションであり、ユーザ操作とWebページの関連を記述する優れたUIを提供します。

3位のJestは、フロントエンドとバックエンドの両方のプロジェクトで用いられる、最も人気のあるテストフレームワークです。

React Testing Libraryは、Kent C. DoddsによるDOM Testing LibraryをラップしたReactアプリのテストソリューションです。
実装の詳細をテストするのではなく、アプリの動作をテストするのに役立つパターンと抽象化を提供します。

モバイル

1位：React Native +11.3k
2位：Quasar +5.0k
3位：Ionic +3.6k
4位：Expo +3.5k
5位：cube-ui +2.6k

コンパイラ

1位：TypeScript +13.9k
2位：Babel +4.2k
3位：Flow +1.7k
4位：Reason +1.3k
5位：Sucrase +1.1k

ビルドツール

1位：Webpack +6.3k
2位：Parcel +5.4k
3位：Rollup +2.7k
4位：Microbundle +1.3k
5位：Gulp +841

CSS in JavaScript

1位：Styled Components +6.0k
2位：Emotion +3.3k
3位：Linaria +2.8k
4位：styled-system +2.4k
5位：CSS Modules +1.8k

GraphQL

1位：Gatsby +11.5k
2位：Hasura GraphQL Engine +8.1k
3位：Prisma +4.5k
4位：Gridsome +3.8k
5位：Apollo client +3.4k

学習リソース

1位：You Don't Know JS +20.1k
2位：30 seconds of code +18.1k
3位：JS Algorithms & Data Structures +17.8k
4位：Node.js Best Practices +16.1k
5位：Tech Interview Handbook +13.0k

まとめ

フロントエンドのトレンドは興味深い傾向を示しています。
Svelteは今後も成長し続けるでしょうか？

あるいは、WebコンポーネントなどWeb標準の採用が増えるでしょうか？

2019年の最も興味深い話のひとつは、AppleがWebコンポーネントを使用する音楽アプリをリリースしたという事実であり、UIフレームワークのひとつであるStencilでコンパイルされています。
これはWebコンポーネントが実アプリに使用された例です。

ネイティブモジュールを使用するアプリをリリースできるという事実は、大きな改善です。

バックエンドでは、Node.jsは登場から10年経ちましたが、今でも新しい機能が精力的に追加され続けています。
v13.2.0の時点で、Node.jsはESモジュールをそのままサポートし、WebAssemblyモジュールをインポートできます。
Workers Threads APIを使えば重いプログラムも実行することができます。

ブラウザにおいてもNode.jsにおいてもプラットフォームは進化し続けており、これがJavaScriptの開発を非常にエキサイティングなものにしてくれます。
ご清聴ありがとうございました。
また来年お会いしましょう！

感想

現在のスター数のランキングではなく、2019年の一年間で増加したスター数のランキングです。
累計は多いけど落ち目の技術はランクに入らないため、最近勢いのある技術がわかります。

総合ランキングは今年もVue.jsの勝利で、堂々の4連覇です。
これから使う技術は、基本的にランキング上位の中から選択しておけば問題ありません。
目的があるのならばそれに適した技術を選ぶべきですが、よくわからないけどなんとなくやってみたい、という段階であれば迷わずVue.jsを選びましょう。
プログラミングは数こそが力なので、わざわざマイナーなものを使ったところでいいことは何もありません。

ところで、昨年までは全てのジャンルに解説があったのですが、今回はランキングだけで解説のないジャンルが目立ちます。
飽きたのでしょうか？

以下はAlbertoM( Webサイト / Twitter / GitHub / dev.to )による記事、Everything you need to know from ES2016 to ES2019の日本語訳です。

Everything you need to know from ES2016 to ES2019

JavaScriptは絶え間なく進化し続けている言語であり、この数年で多くの新機能がECMAScriptの仕様に追加されました。

この記事は私の著書Complete Guide to Modern JavaScriptからの抜粋であり、そしてこの本はES2016・ES2017・ES2018・ES2019の新しい機能について解説しています。

記事の最後に、全てを要約したチートシートを用意しています。

Everything new in ES2016

ES2016で追加された機能はわずか二つです。
・Array.prototype.includes()
・指数演算子

Array.prototype.includes()

includes()メソッドは、配列に特定の値が含まれる場合はtrueを返し、含まれていなければfalseを返します。

letarray=[1,2,4,5];array.includes(2);// truearray.includes(3);// false

Combine includes() with fromIndex

検索を開始するインデックスをincludes()に渡すことができます。
デフォルトは0で、負の値を渡すこともできます。
最初の値は検索する要素で、2番目の値は開始インデックスです。

letarray=[1,3,5,7,9,11];array.includes(3,1);// true 1番目つまり最初から検索開始するarray.includes(5,4);// falsearray.includes(1,-1);// false 最後尾から検索開始するarray.includes(11,-3);// true

array.includes(5,4);はfalseを返します。
4番目の値から検索を開始するため、2番目にある値5は検索範囲外だからです。

array.includes(1,-1);はfalseを返します。
インデックス-1は配列の最後の要素という意味で、そこから検索を開始するためです。

array.includes(11,-3);はtrueを返します。
インデックス-3は配列の最後から3番目の要素という意味で、そこから検索を始めたため範囲内に11を発見しました。

The exponential operator

ES2016より前は、以下のように書いていました。

Math.pow(2,2);// 4Math.pow(2,3);// 8

指数演算子の導入により、以下のように書けるようになりました。

2**2;// 42**3;// 8

複数の演算を組み合わせる際に特に役立ちます。

2**2**2;// 16Math.pow(Math.pow(2,2),2);// 16

Math.pow()を使うと長く面倒な書式になります。
指数演算子を使うと、同じことをより早くよりクリーンに記述することができます。

ES2017 string padding, Object.entries(), Object.values() and more

ES2017では、多くのクールな新機能が追加されました。
それらを以下に解説していきます。

String padding (.padStart() and .padEnd())

文字列の先頭もしくは末尾にパディングを付けられます。

"hello".padStart(6);// " hello""hello".padEnd(6);// "hello "

パディング値に6を指定したのに、スペースが1しか入らなかったのはなぜでしょう。
padStartとpadEndは規定文字数になるように穴埋めするからです。
上記例の場合、"hello"は5文字あるため、不足した1文字だけがパディングされました。

"hi".padStart(10);// "        hi" 8文字埋められた"welcome".padStart(10);// "   welcome" 4文字埋められた

Right align with padStart

値を右揃えしたいときにもpadStartが使えます。

conststrings=["short","medium length","very long string"];constlongestString=strings.sort(str=>str.length).map(str=>str.length)[0];strings.forEach(str=>console.log(str.padStart(longestString)));// very long string//    medium length//            short

まず、最も長い文字列の長さを取得します。
次いですべての文字列にpadStartを適用し、文字列長を最も長い文字列に合わせました。

Add a custom value to the padding

スペースだけではなく、任意の文字でパディングすることができます。

"hello".padEnd(13," Alberto");// "hello Alberto""1".padStart(3,0);// "001""99".padStart(3,0);// "099"

Object.entries() and Object.values()

とりあえずObjectを作成します。

constfamily={father:"Jonathan Kent",mother:"Martha Kent",son:"Clark Kent",}

かつてのJavaScriptは、プロパティに以下のようにアクセスしていました。

Object.keys(family);// ["father", "mother", "son"]family.father;// "Jonathan Kent"

Object.keys()は、プロパティのキーのみを返します。

ES2017では、プロパティにアクセスする方法が2種類増えました。

Object.values(family);// ["Jonathan Kent", "Martha Kent", "Clark Kent"]Object.entries(family);// ["father", "Jonathan Kent"]// ["mother", "Martha Kent"]// ["son", "Clark Kent"]

Object.values()はプロパティ値のみの配列を返し、Object.entries()はキーと値の両方を含む配列の配列を返します。

Object.getOwnPropertyDescriptors()

このメソッドは、オブジェクトの持つ全てのプロパティディスクリプタを返します。
ディスクリプタの属性はvalue・writable・get・set・configurable・enumerableです。

constmyObj={name:"Alberto",age:25,greet(){console.log("hello");},}Object.getOwnPropertyDescriptors(myObj);// age:{value: 25, writable: true, enumerable: true, configurable: true}// greet:{value: ƒ, writable: true, enumerable: true, configurable: true}// name:{value: "Alberto", writable: true, enumerable: true, configurable: true}

Trailing commas in function parameter lists and calls

これは、本当に小さな変更です。
しかしこれで、そのパラメータが最後であるかどうかをいちいち気にせずに末尾カンマを書けるようになりました。

// 昔constobject={prop1:"prop",prop2:"propop"}// 現在constobject={prop1:"prop",prop2:"propop",}

2番目のプロパティは最後にカンマが増えていることに注目してください。
入れなくてもエラーにはなりませんが、同僚やチームメイトの生活を楽にするためにも入れておくことをお勧めします。

// カンマ入れないconstobject={prop1:"prop",prop2:"propop"}// 同僚が最終行をコピペしてプロパティを追加したconstobject={prop1:"prop",prop2:"propop"prop3:"propopop"}// 突然エラーが出るようになった

Shared memory and Atomics

MDNによると (日本語版)

メモリーが共有されている場合、複数のスレッドがメモリー内の同じデータを読み書きできます。アトミック演算では、予測される値の書き込みと読み込みを保証するため、次の演算が開始される前に現在の演算が完了し、その演算が割り込まれないようにします。

Atomicはコンストラクタではありません。
プロパティとメソッドは全て静的であり、newしたりinvokeしたり関数として呼び出したりすることはできません。

Atomicが持つメソッドは以下のようなものがあります。
・ add / sub
・ and / or / xor
・ load / store

Atomicは、汎用固定長バイナリデータバッファSharedArrayBufferなどで使用されます。
いくつかの例を見てみましょう。

Atomics.add(), Atomics.sub(), Atomics.load() and Atomics.store()

// SharedArrayBuffer作成constbuffer=newSharedArrayBuffer(16);constuint8=newUint8Array(buffer);// これに各計算するuint8[0]=10;console.log(Atomics.add(uint8,0,5));// 10console.log(uint8[0])// 15console.log(Atomics.load(uint8,0));// 15

最初のAtomics.add()は加算を行いますが、返り値は計算する前の値です。
その後uint8[0]を参照すると、addが実行されたあとなので値が15になっていることが確認できます。

配列値をAtomicに取得するにはAtomics.load()を使い、第一引数が対象の配列、第二引数がインデックスです。

Atomics.sub()はAtomics.add()と同じ挙動で、減算を行います。

// SharedArrayBuffer作成constbuffer=newSharedArrayBuffer(16);constuint8=newUint8Array(buffer);// これに各計算するuint8[0]=10;console.log(Atomics.sub(uint8,0,5));// 10console.log(uint8[0])// 5console.log(Atomics.store(uint8,0,3));// 3console.log(Atomics.load(uint8,0));// 3

Atomics.sub()を使って10から5を引きました。
計算自体の返り値は、Atomics.add()と同じく計算する前の値であり、すなわち10です。

次にAtomics.store()を使い特定の値、今回は配列の0番目のインデックスに3を登録しました。

Atomics.store()は渡した値をそのまま返します。
Atomics.load()すると、値は書き替えられた後なので5ではなく3になります。

Atomics.and(), Atomics.or() and Atomics.xor()

これらはそれぞれAND、OR、XORのビット演算を行います。
ビット演算の詳細はWikipediaなどで読むことができます。

ES2017 Async and Await

ES2017では、async/awaitと呼ばれる新たなPromiseが導入されました。

Promise review

その前に、まず普通のPromise構文を簡単に復習しましょう。

// GitHubからユーザを取得fetch('api.github.com/user/AlbertoMontalesi').then(res=>{// 値をJSONで返すreturnres.json();}).then(res=>{// 全てが正常に動作したらここに来るconsole.log(res);}).catch(err=>{// エラーがあったらここに来るconsole.log(err);})

GitHubからユーザを取得してコンソールに出力するだけの簡単な例です。

また別の例を見てみましょう。

functionwalk(amount){returnnewPromise((resolve,reject)=>{if(amount<500){reject("the value is too small");}setTimeout(()=>resolve(`you walked for ${amount}ms`),amount);});}walk(1000).then(res=>{console.log(res);returnwalk(500);}).then(res=>{console.log(res);returnwalk(700);}).then(res=>{console.log(res);returnwalk(800);}).then(res=>{console.log(res);returnwalk(100);}).then(res=>{console.log(res);returnwalk(400);}).then(res=>{console.log(res);returnwalk(600);});// you walked for 1000ms// you walked for 500ms// you walked for 700ms// you walked for 800ms// uncaught exception: the value is too small

Async and Await

これをasync/awaitで書き換えるとこうなります。

functionwalk(amount){returnnewPromise((resolve,reject)=>{if(amount<500){reject("the value is too small");}setTimeout(()=>resolve(`you walked for ${amount}ms`),amount);});}// asyncなfunctionを作成asyncfunctiongo(){// awaitがあれば終わるまで待つconstres=awaitwalk(500);console.log(res);constres2=awaitwalk(900);console.log(res2);constres3=awaitwalk(600);console.log(res3);constres4=awaitwalk(700);console.log(res4);constres5=awaitwalk(400);console.log(res5);console.log("finished");}go();// you walked for 500ms // you walked for 900ms // you walked for 600ms // you walked for 700ms // uncaught exception: the value is too small

非同期関数を作成するには、まずasyncキーワードを記載します。
このキーワードが入った関数はPromiseを返すようになります。
Promiseでない値を返そうとした場合、自動的にPromiseでラップされて返されます。
awaitキーワードは、async関数内でのみ機能します。
awaitを書くと、プログラムはPromiseが結果を返すまでそこで停止します。

async関数の外でawaitキーワードを使うとどうなるでしょうか。

// asyncではない関数functionfunc(){letpromise=Promise.resolve(1);letresult=awaitpromise;}func();// SyntaxError: await is only valid in async functions and async generators// トップレベルletresponse=Promise.resolve("hi");letresult=awaitresponse;// SyntaxError: await is only valid in async functions and async generators

復習：awaitは、async関数内でのみ使用可能。

Error handling

Promiseではエラーを.catch()でキャッチします。
これについては特に違いはありません。

asyncfunctionasyncFunc(){try{letresponse=awaitfetch('http:your-url');}catch(err){console.log(err);}}asyncFunc();// TypeError: failed to fetch

関数内でエラーハンドリングしていない場合は、以下のように書くこともできます。

asyncfunctionasyncFunc(){letresponse=awaitfetch('http:your-url');}asyncFunc();// Uncaught (in promise) TypeError: Failed to fetchasyncFunc().catch(console.log);// TypeError: Failed to fetch

ES2018 Async Iteration and more?

ES2018で導入された機能も見ていきましょう。

Rest / Spread for Objects

ES6 (ES2015) でスプレッド構文が導入されたことを覚えていますか？

constveggie=["tomato","cucumber","beans"];constmeat=["pork","beef","chicken"];constmenu=[...veggie,"pasta",...meat];console.log(menu);// Array [ "tomato", "cucumber", "beans", "pasta", "pork", "beef", "chicken" ]

スプレッド構文にRestパラメータがオブジェクトに対しても使用可能になりました。

letmyObj={a:1,b:3,c:5,d:8,}// zは残り全部let{a,b,...z}=myObj;console.log(a);// 1console.log(b);// 3console.log(z);// {c: 5, d: 8}// スプレッド構文でクローンletclone={...myObj};console.log(clone);// {a: 1, b: 3, c: 5, d: 8}myObj.e=15;console.log(clone)// {a: 1, b: 3, c: 5, d: 8}console.log(myObj)// {a: 1, b: 3, c: 5, d: 8, e: 15}

スプレッド構文を使うとオブジェクトのクローンが簡単に作成できます。
元のオブジェクトを変更しても、クローンしたオブジェクトは変更されません。

Asynchronous Iteration

非同期イテレータを用いて、データを非同期的に反復することができます。

ドキュメントによると、

非同期イテレータは、next()メソッドが{ value, done }のペアを返すこと以外、イテレータにそっくりです。

従って、for-await-ofループで反復処理してPromiseにすることができます。

constiterables=[1,2,3];asyncfunctiontest(){forawait(constvalueofiterables){console.log(value);}}test();// 1// 2// 3

ループの実行中、[Symbol.asyncIterator]()を用いてデータソースから非同期イテレータを作成します。
次のループにアクセスするたびに、返ってきたPromiseを暗黙的にawaitします。

Promise.prototype.finally()

Promiseが終了したときに呼び出されます。

constmyPromise=newPromise((resolve,reject)=>{resolve();})myPromise.then(()=>{console.log('still working');}).catch(()=>{console.log('there was an error');}).finally(()=>{console.log('Done!');})

.finally()もPromiseを返すので、さらにthenやcatchを続けることも可能ですが、そこに渡ってくるPromiseはfinallyではなく元の値です。

constmyPromise=newPromise((resolve,reject)=>{resolve();})myPromise.then(()=>{console.log('still working');return'still working';}).finally(()=>{console.log('Done!');return'Done!';}).then(res=>{console.log(res);// still working})

見てのとおり、最後のthenに渡ってくるPromiseは、finallyによるものではなく最初のthenが作ったものです。

RegExp features

正規表現の機能が4種類追加されました。

s(dotAll) flag for regular expressions

sフラグが導入されました。
これにより、'.'が改行を含む任意の1文字に一致するようになります。

/foo.bar/s.test('foo\nbar');// true

RegExp named capture groups

ドキュメントによると、

番号付きキャプチャグループを使用して、正規表現が一致した文字列の特定の個所を参照することができます。
キャプチャグループには一意の番号が割り当てられており、その番号で参照することができますが、これにより正規表現の把握とリファクタリングが難しくなります。
日付に一致する/(\d{4})-(\d{2})-(\d{2})/を例に取ると、どの番号が月に対応し、どの番号が日に対応しているかは、コードをよく調べてみないと理解できません。
また月と日の順番を入れ替えたいとなったら、参照する番号の方まで書き換えなければなりません。
ここでキャプチャグループに(?<name>...)構文を用いて、識別子nameで参照することができるようになります。
日付の正規表現を/(?<year>\d{4})-(?<month>\d{2})-(?<day>\d{2})/uと書けます。
各識別子は一意であり、ECMAScriptの命名規則に従う必要があります。
名前付きキャプチャグループには、返り値のgroupsプロパティからアクセスすることができます。
以下の例のように、名前付きキャプチャグループと同時に、番号付きの参照も作成されます。

letre=/(?<year>\d{4})-(?<month>\d{2})-(?<day>\d{2})/u;letresult=re.exec('2015-01-02');// result.groups.year === '2015';// result.groups.month === '01';// result.groups.day === '02';// result[0] === '2015-01-02';// result[1] === '2015';// result[2] === '01';// result[3] === '02';let{groups:{one,two}}=/^(?<one>.*):(?<two>.*)$/u.exec('foo:bar');console.log(`one: ${one}, two: ${two}`);// one: foo, two: bar

RegExp Lookbehind Assertions

ドキュメントによると、

後読みアサーションを使用すると、手前に別のパターンが存在するパターンにマッチすることができます。
たとえば$記号を含まずに金額だけマッチするような使い方ができます。
肯定後読みアサーションは(?<=...)と記述します。
$記号を含まずに金額だけマッチさせたい場合は/(?<=$)\d+(\.\d*)?/とし、これは$10.53にマッチして10.53がキャプチャされます。
しかし€10.53にはマッチしません。
否定後読みアサーションは(?<!...)と記述し、手前に別のパターンが存在しないパターンにマッチします。
/(?<!$)\d+(?:\.\d*)/は$10.53にマッチしませんが、€10.53にはマッチします。

RegExp Unicode Property Escapes

ドキュメントによると、

\p{…}および\P{…}形式のUnicodeプロパティエスケープが追加されます。
Unicodeプロパティエスケープは、uフラグの指定された正規表現で使用可能な新しいタイプのエスケープシーケンスです。
これを使うと、以下のような記述が可能になります。

constregexGreekSymbol=/\p{Script=Greek}/u;regexGreekSymbol.test('π');// true

Lifting template literals restriction

タグ付きテンプレートリテラルを使うと、エスケープシーケンスの制限を気にする必要がなくなります。
詳細はこちらをご覧ください。

What's new in ES2019?

ECMAScriptの最新バージョンである、ES2019で追加されたものを見ていきましょう。

Array.prototype.flat() / Array.prototype.flatMap()

Array.prototype.flat()は、指定された深さまでの配列を再帰的にフラット化します。
深さ引数のデフォルトは1です。
Infinityを指定すると、無制限にネストを解除します。

constletters=['a','b',['c','d',['e','f']]];// デフォルトは1letters.flat();// ['a', 'b', 'c', 'd', ['e', 'f']]// 2段階letters.flat(2);// ['a', 'b', 'c', 'd', 'e', 'f']// 2段 = 1段 * 2letters.flat().flat();// ['a', 'b', 'c', 'd', 'e', 'f']// ネストがなくなるまで再帰的にフラット化letters.flat(Infinity)// ['a', 'b', 'c', 'd', 'e', 'f']

Array.prototype.flatMap()は、引数の取り扱いはflat()と同じです。
配列を単純にフラット化するのではなく、関数を渡して任意の処理を行うことができます。

letgreeting=["Greetings from","","Vietnam"];// 普通のmapgreeting.map(x=>x.split(""));// ["Greetings", "from"]// ["", ""]// ["Vietnam"]// mapしてflatgreeting.flatMap(x=>x.split(""))// ["Greetings", "from", "", "", "Vietnam"]

普通にmap()を使うと、ネストした配列になります。
flatMap()を使うことでフラットな配列にすることができます。

Object.fromEntries()

Key-valueペアからオブジェクトに変換します。

constkeyValueArray=[['key1','value1'],['key2','value2']]constobj=Object.fromEntries(keyValueArray)// {key1: "value1", key2: "value2"}

Object.fromEntries()は引数として配列、Map、その他の反復可能プロトコルを受け取ります。
反復可能プロトコルの詳細についてはこちらをご覧ください。

String.prototype.trimStart() / .trimEnd()

String.prototype.trimStart()は文字列の先頭にある空白を削除し、String.prototype.trimEnd()は文字列の末尾にある空白を削除します。

letstr="    this string has a lot of whitespace   ";str.length;// 42str=str.trimStart();// "this string has a lot of whitespace   "str.length;// 38str=str.trimEnd();// "this string has a lot of whitespace"str.length;// 35

trimStart()のエイリアスとしてtrimLeft()が、trimEnd()のエイリアスとしてtrimRight()が存在します。

Optional Catch Binding

ES2019より前は、catch句に必ず例外変数を取る必要がありました。
ES2019では省略することができます。

// Beforetry{...}catch(error){...}// ES2019try{...}catch{...}

エラーを無視したいときに便利です。
この機能のユースケースについてはこの記事を強くお勧めします。

Function​.prototype​.toString()

関数の.toString()は、ソースコードを文字列として返します。

functionsum(a,b){returna+b;}console.log(sum.toString());// function sum(a, b) {//    return a + b;//  }

コメントも含みます。

functionsum(a,b){// perform a sumreturna+b;}console.log(sum.toString());// function sum(a, b) {//   // perform a sum//   return a + b;// }

Symbol.prototype.description

.descriptionはSymbolの値を文字列で返します。

constme=Symbol("Alberto");me.description;// "Alberto"me.toString()//  "Symbol(Alberto)"

Download the cheatsheet

このリンクから、これらのチートシートをダウンロードすることができます。

よかったらAmazonやLeanpubで私の本を買ったり、Educativeのコースを受けてみてください。

感想

全てと言いつつ全てではありませんが、これは元々著者がThe Complete Guide to Modern JavaScriptという書籍を出していて、この記事はその抜粋だからです。

抜粋といってもわりとけっこうな分量でしたが、元の本は全300ページという更に相当な力作となっています。
最初は変数や関数といった基礎部分から順にステップアップしていく内容で、この記事で紹介されている新機能は200ページ以降に出てくる、いわばおまけ部分です。
全編英語なのでなかなかたいへんですが、読み通せば現代のJavaScript事情に詳しくなれることは間違いありません。
しかもKindleなら2000円弱と大変お買い得、これは持ってて正解ですね。

以下はCloudflareによるレポート、JavaScript Libraries Are Almost Never Updated Once Installedの日本語訳です。

JavaScript Libraries Are Almost Never Updated Once Installed

Cloudflareは、WebページにJavaScriptやその他のフロントエンドリソースを配置するための一般的な方法である、CDNJSを支援しています。
今回我々は、CDNJSチームの許可を得て、CDNJSへのリクエストから匿名化・集約されたデータを収集し、インターネットでWebサイトがどのように構築されているかを分析することにしました。
今回のエントリでは、ひとつの疑問に焦点を当てています。
すなわち、いちどJavaScriptライブラリをサイトにインストールしたあとで、ライブラリは更新されるでしょうか？

まずは地球上でもっとも人気のあるライブラリ、jQueryから始めましょう。
このチャートは、過去12か月間の、jQueryのバージョンごとのリクエスト数を表しています。

2019年5月2日のリリース以降、バージョン3.4.1のリクエスト数は着実に増加しています。
しかし、古いバージョンが減少しているということはありません。
バージョン3.2.1は、チャートのはじめには一日あたり3600万のリクエストがありましたが、一年の終わりには2900万リクエストとなり、20%減少しています。
しかしこれは、平均的なWebサイトは2～4年しか保たないというリサーチの結果と一致しています。
バージョン3.4.1は着実に普及しつつありますが、しかしそれに伴って古いバージョンが減少するような傾向は全くありません。

ちなみにCDNJSに入っているjQueryの最も古いバージョンは、2013年5月25日にリリースされた1.10.0です。
これはいまだに一日平均10万件のリクエストがあり、それらを使っているサイトの人気も依然として衰えていないどころか、さらに高まっています。

jQueryだけの特異な現象でないことを示すために、別のプロジェクトTweenMaxも見てみましょう。

このパッケージは利用者がjQueryほど多くないため、データは一週間ごとの平均で平滑化されています。

バージョン1.20.4は1800万件のリクエストで始まり、1400万件で終わりました。
Webサイトの消滅割合と概ね同じ23%の減少です。
2.1.3の大きな成長は同時に、新バージョンのリリースが旧バージョンの人気にほとんど影響を与えないという明白な証拠を示しています。
2.1.3が2900万リクエストまで増加しても、旧バージョンへのリクエスト数は全く変わっていません。

結果として言えることは、一度公開されたライブラリを使うWebサイトは永久に存在し続けるということです。
従って、Web基盤プラットフォームは、あらゆるWebをサポートするためには、どれほど古いライブラリでも無期限に提供し続けなければなりません。

Cloudflareは、最新のWebにコントリビュートすることに非常に興味を持っています。
ぜひコメントで提案してください。

コメント欄

「CDNJS依存関係を自動でバージョンアップするRenovate Botってのを作ってる。」
「古いライブラリ使ってる人に通知するとか。」
「Wappalyzerみたいなかんじでバージョンが古いのを一目でわかるようにするとか。」
「@majorみたいなセマンティックバージョンを提供するとか。」「マイナーバージョンで互換性なくすアプデしてくるライブラリを腐るほど見たからまあ無理だろ。」
「CDNが落ちてた時にローカルのライブラリを読ませてるんだけど、バージョン揃えるのが面倒。自動更新とかできない？」「ASP.NETだけどそういうのはある。」「jQueryにもあった気がする。」

感想

要するに、継続的なんちゃらだとかリーンなんちゃらだとか言ってるのは業界の極一部でしかなく、大半のサイトは一度作ったらそれっきりということです。
実際そんな最前線を走り続けなければならないサイトなんてほとんどありませんからね。
GAFAMでも配信サイトでもない一般人のサイトが最新技術を駆使してます！なんて言われてもどうでもよくない？

コメントで言っているセマンティックバージョンはこれのことです。
ざっくり言うと『互換性の無いバージョンアップはメジャーバージョンを上げろ』ですが、これが守られているライブラリなんてほとんど存在しないことは周知のとおりです。

といってもさすがに今どきjQuery1は、さすがに古すぎますね。
jQuery2が出たのが2013年4月。
当時小学校に入った子供が既に中学生になっているほどの昔ですよ。

あと今回見せてるのはjQueryとTweenMaxだけなので、VueとかReactとか最近のやつもちょっと見てみたかったですね。

ある文字列中に特定の文字列が存在するかを調べる方法としてstrposが存在します。

しかし、そもそもstrposは『ある文字列中で特定の文字列が何文字目に出てくるか』を調べる関数であり、第一に使用目的が異なる関数です。
そしてこちらも有名な話ですが、先頭が一致すると0が返ってくるので、緩やかな比較ではfalseと区別されません。
PHPのよくある落とし穴のひとつです。

if(strpos('放課後アトリエといろ','アトリエ')){echo'"放課後アトリエといろ"には"アトリエ"が含まれる';// 表示される}if(strpos('放課後アトリエといろ','放課後')){echo'"放課後アトリエといろ"には"放課後"が含まれる';// 表示されない！！}if(strpos('放課後アトリエといろ','放課後')!==false){echo'"放課後アトリエといろ"には"放課後"が含まれる';// 表示される}

マニュアルにも大きく警告が出されています。

この状況がついにPHP8で変わります。

PHP RFC: str_contains

Introduction

str_containsは、ある文字列に特定の文字列が含まれているかをチェックし、見つかったか否かによってtrue/falseいずれかのbooleanを返します。

ある文字列に特定の文字列が含まれているかをチェックするために、一般的にはstrposやstrstrが使用されます。
str_containsは凡そあらゆるプロジェクトで非常によく使われるユースケースなので、独自の関数を追加するに値するはずです。
strposやstrstrには、いくつかの欠点が存在します。

・あまり直感的ではない
・間違いをしやすい(特に!==の場合)
・新規PHP開発者が覚えにくい

このため、多くのPHPフレームワークは独自のヘルパ関数を提供しています。
このことこそがstr_containsの重要性や必要性をよく示しています。

Proposal

このRFCは、新しい関数str_containsを提唱します。

str_contains(string$haystack,string$needle):bool

引数$haystackと$needleを取り、$haystackの中に$needleが存在するか否かをbooleanで返します。

str_contains("abc","a");// truestr_contains("abc","d");// false// 空文字列はtrueになるstr_contains("abc","");// truestr_contains("","");// true

空文字列の扱いについて。

As of PHP 8, behavior of '' in string search functions is well defined, and we consider '' to occur at every position in the string, including one past the end. As such, both of these will (or at least should) return true. The empty string is contained in every string.

PHP8において、文字列検索関数において''の動作は明確に定義されており、終端を含む文字列全ての位置にマッチします。そのため、これらは両方ともtrueを返すべきです。空文字はあらゆる文字列に含まれています。 - Nikita Popov

Case-insensitivity and multibyte strings

internalメーリングリストなどの議論において、この関数のマルチバイト対応版(mb_str_contains)は必要ないという結論に達しました。
理由として、この関数のマルチバイト版は非マルチバイト版と全く同じ動作になります。
文字列の見付かった位置によって動作が異なる場合は、マルチバイト版は異なる動作になります。
この関数は見付かった位置によって動作は変わらないので、マルチバイト版の必要はありません。

大文字と小文字を区別しない版については、需要が大文字と小文字を区別する版よりはるかに低いため、このRFCには含まれません。
区別しない版を取り込むと、有効なバリアントはstr_contains/mb_str_icontainsだけになります。
このように中途半端なバリアントをいきなり提供するとPHP開発者が混乱する可能性があるので、最初は小さく始めた方がよいでしょう。

Backward Incompatible Changes

PHP自体に後方互換性のない変更はありません。

ユーザランドに同じ関数が実装されている場合、非互換の可能性があります。
しかし、そのようなグローバル関数はアプリケーションの起動プロセスのかなり早い段階で追加されるので、開発者はこの問題にすぐ気付くでしょう。

Proposed PHP Version(s)

PHP 8

Implementation

str_contains関数は、このプルリクで実装されています。
https://github.com/php/php-src/pull/5179

投票

投票は2020/03/16まで、受理には2/3の賛成が必要です。
2020/03/09時点では賛成43反対5で、まず間違いなく受理されます。

感想

よく考えたらずっと前からあってもおかしくない関数なのに、これまで存在してなかったのは不思議ですね。

実際のところ、文字数としてはわずか2字の差にすぎません。

if(strpos($heystack,$needle)!==false){echo'$heystackに$needleが含まれている';}// 同じif(str_contains($heystack,$needle)){echo'$heystackに$needleが含まれている';}

しかし、読みやすさ、理解のしやすさという点では圧倒的にstr_containsに分がありますね。

以下はマルチバイト対応関数が用意されない点の補足です。
マルチバイト対応strposとしてmb_strposがありますが、文字が存在するか否かをチェックするだけであれば実はstrposでも問題ありません。

echostrpos('あい','い');// 3echomb_strpos('あい','い');// 1echostrpos('あい','あ');// 0echomb_strpos('あい','あ');// 0echostrpos('あい','う');// falseechomb_strpos('あい','う');// false

値が変わるのは『存在したときの文字数の数え方』だけです。
文字列の有無を確認するだけであれば、存在しない場合は常にfalse、存在する場合は常にint型となって差が出ないわけですね。

同様にstr_containsも、存在しない場合は常にfalse、存在する場合は常にtrueなるため、あえてmb_str_containsを用意する必要はないというわけです。

MDNに非同期 JavaScriptという学習項目があるのですが、目次以外は日本語がありません。
ということで以下はIntroducing asynchronous JavaScript項目の日本語訳です。

Introducing asynchronous JavaScript

この記事では、同期JavaScriptにまつわる問題点を簡潔に要約します。
そして非同期JavaScriptのテクニックの幾つかを紹介し、それぞれが問題点の解決にどのように役立つかを示します。

前提条件：基礎的なコンピュータリテラシー、JavaScriptの基礎をある程度理解していること。
目的：非同期JavaScriptとは何か、同期JavaScriptとは何が違うのか、どのようなユースケースが存在するか、ということを理解する。

同期JavaScript

非同期JavaScriptが何であるのかを理解するためには、まず同期JavaScriptが何であるかを理解することから始めなければなりません。
このセクションでは、前回の記事で現れた情報の一部を要約します。

これまでに学習してきた多くの機能は、そのほとんどが同期です。
幾つかのコードを実行してみると、ブラウザはそれを実行すると同時に結果を返します。
簡単な例を見てみましょう。
実際の動作はこちらで、ソースはこちらで見ることができます。

constbtn=document.querySelector('button');btn.addEventListener('click',()=>{alert('You clicked me!');letpElem=document.createElement('p');pElem.textContent='This is a newly-added paragraph.';document.body.appendChild(pElem);});

このブロックは、処理が上から順番に実行されます。

1. 利用可能な要素をDOMから探し出す。
2. クリックしたときに発火するclickイベントリスナーを設定する。
   1. alert()でメッセージボックスを出す。
   2. アラートが消えたら<p>要素を生成する。
   3. そこにテキストを登録する。
   4. 最後にドキュメントボディに要素を追加する。

それぞれの処理が行われている間、他には何も起こりません。
レンダリングは一時停止されます。
これは、前回の記事で述べたように、JavaScriptがシングルスレッドであるためです。
ひとつのスレッドで一度に発生させることができるイベントはひとつだけであり、他のすべてはイベントが終了するまでブロックされます。

従って上記の例では、ボタンをクリックすると、その後アラートでOKボタンを押すまで、次の段落は表示されません。
実際に以下で試してみることができます。
https://codepen.io/pen/?&editable=true
https://jsfiddle.net/api/mdn/

注意：alert()は同期によるブロッキングを示すためのデモンストレーションとして使うのには最適ですが、実アプリで使用するととても残念なことになるので注意が必要です。

非同期JavaScript

前述のブロッキングといった問題を回避するため、多くのWeb APIは非同期コードを使って実行されるようになりました。
特に何らかの外部デバイスにアクセスしたりフェッチしたりするもの、たとえばネットワーク経由でファイルを取得する、データベースにアクセスしてデータを返す、Webカメラからビデオストリームにアクセスする、VRヘッドセットに出力をブロードキャストする、といったものです。

同期JavaScriptでこれらを実現するのが難しいのは何故でしょうか。
以下に簡単な例を見てみましょう。
サーバから画像を取得する場合、即座に結果を得ることはできません。
すなわち、以下の擬似コードはおそらく動作しないだろう、ということです。

varresponse=fetch('myImage.png');varblob=response.blob();// 画像を何処かのUIに表示する

理由は、画像のダウンロードにかかる時間がわからないためです。
時間がかかった場合、2行目に辿り着いた時点でresponseはまだ使用できません。
従って、時々あるいは毎回、2行目でエラーが発生することでしょう。
これを回避するため、responseを使用するときはresponseが使用可能になるまで待機しておく必要があります。

JavaScriptで扱える非同期コードのスタイルは主に2種類が存在します。
古いスタイルのコールバック形式と、Promiseを使った新しい形式のコードです。
以下のセクションでは、それぞれを順に解説します。

非同期コールバック

非同期コールバックは、バックグラウンドで動作するコードを呼び出すときにパラメータとして指定する関数です。
バックグラウンドコードは、実行が終了するとコールバック関数を呼び出して、自分が終了したことを知らせます。
あるいは特に注意すべきことが発生した際に通知します。

非同期コールバックは少々時代遅れになりつつありますが、いま一般に使われている歴史の長いAPIではまだまだ使用されています。
以下は非同期コールバック関数をaddEventListener()の第二引数に与える例です。

btn.addEventListener('click',()=>{alert('You clicked me!');letpElem=document.createElement('p');pElem.textContent='This is a newly-added paragraph.';document.body.appendChild(pElem);});

第一引数には監視するイベントのタイプを指定し、第二引数がイベントが発生したときに呼び出されるコールバック関数です。
コールバック関数をパラメータとして別の関数に渡す際、別の関数を実行した時点でコールバック関数まで実行されることはありません。
別の関数内部の何処かで非同期的にコールバックされます(これが名前の由来です)。
別の関数は、対象のイベントが発生したときにコールバック関数を実行します。

コールバック関数を含む関数は独自に実装することが簡単にできます。
ここではXMLHttpRequest APIを使った例を見てみましょう。
実際の動作はこちらで、ソースはこちらで見ることができます。

functionloadAsset(url,type,callback){letxhr=newXMLHttpRequest();xhr.open('GET',url);xhr.responseType=type;xhr.onload=function(){callback(xhr.response);};xhr.send();}functiondisplayImage(blob){letobjectURL=URL.createObjectURL(blob);letimage=document.createElement('img');image.src=objectURL;document.body.appendChild(image);}loadAsset('coffee.jpg','blob',displayImage);

引数のobject URLを表示するimgタグを作ってドキュメントのbodyに追加する関数displayImage()を作りました。
次いで、URLとコンテンツタイプ、そしてコールバックを引数として受け取るloadAsset()関数を作ります。
この関数は、XMLHttpRequest(よくXHRと略される)を使って指定されたURLのリソースをフェッチし、返ってきたレスポンスをコールバック関数に渡します。
loadAsset()関数にコールバックとして渡されたdisplayImage()関数はすぐに動作するのではなく、XHRによるリソースのダウンロードが完了するまで待機します。
待機はonloadイベントハンドラで実現されています。

コールバックは汎用性があります。
関数の実行順序や関数間で渡すデータを制御できるだけではなく、状況に応じて異なる関数を呼び出すこともできます。
レスポンスの内容によってprocessJSON()関数を実行したり、displayText()関数を実行したりといった様々なアクションを持たせることができます。

全てのコールバックが非同期であるわけではないことに注意してください。
以下はArray.prototype.forEach()を用いて配列項目をループする例です。
実際の動作はこちらで、ソースはこちらで見ることができます。

constgods=['Apollo','Artemis','Ares','Zeus'];gods.forEach(function(eachName,index){console.log(index+'. '+eachName);});

この例は、ギリシャの神々の配列をループし、インデックスと値をコンソールに出力するものです。
foreach()が期待するパラメータは配列インデックスと値の2値を引数として持つコールバック関数です。
ただし、このコールバック関数は一切待機せずに即座に実行されます。

Promises

Promiseは、モダンなWebAPIで使用される、新しいスタイルの非同期コードです。
よくある例はfetch() APIで、これは要するにXMLHttpRequestの現代版スタイルのようなものです。
サーバからのデータ取得から簡単な例を見てみましょう。

fetch('products.json').then(function(response){returnresponse.json();}).then(function(json){products=json;initialize();}).catch(function(err){console.log('Fetch problem: '+err.message);});

実際の動作はこちらで、ソースはこちらで見ることができます。

fetch()は取得したいリソースのURLひとつだけを引数に取り、そしてPromiseオブジェクトを返します。
Promiseは最終的に非同期操作が完了したかもしくは失敗したかのステータスを持つオブジェクトで、それまではどちらでもない中間状態になっています。
『わかり次第すぐに結果を返すことを約束する』という概念であるため、"promise"という名前が付いています。

この概念に慣れるのは少し練習が必要です。
これはシュレディンガーの猫に似ていると言えるかもしれません。
成功失敗どちらの結果もまだ発生していない状態では、fetch()はまだ実行を完了せず、次の操作を保留します。
結果がわかったときに、fetch()の次にある3つのコードブロックが呼び出されます。

・ふたつあるthen()ブロックは、いずれもその前の操作が成功した場合に呼び出されるコールバック関数です。
各コールバックは、その前の操作が成功した場合に返した結果を入力として受け取ります。
各then()ブロックはそれぞれ別のpromiseを返すため、then()ブロックをいくつも連ねて、複数の非同期操作を順番に実行することができます。

・catch()ブロックは、どこかのthen()ブロックが失敗したときに実行されます。
同期のtry...catchブロックと似たようなもので、catch()ブロックはエラーオブジェクトを受け取ります。
これは発生したエラーの種類を判断するために使用できます。
後ほど解説しますが、同期try...catchはpromise内で使用することはできません。
async/awaitを使っている場合は使用可能です。

注：promiseについては後から詳しく解説するので、まだ完全に理解できてなくても大丈夫です。

The event queue

Promiseなどの非同期操作はイベントキューに入れられ、メインスレッドの処理が完了した後で実行されるため、後続のJavaScriptコードの実行をブロックしません。
キューに入れられた処理は、なるべく早めに処理が行われ、結果がJavaScriptに返されます。

Promises versus callbacks

Pormiseは、古い形式のコールバックと多少の類似点があります。
これらはコールバック関数を呼び出すオブジェクトであって、コールバックそのものを関数に渡す必要はありません。

しかしながら、Promiseは非同期処理を容易にするために設計されており、古い形式のコールバックよりも多くの利点が存在します。

・複数の非同期操作を.then()を使って連結し、最初の操作の返り値を次の操作の入力に渡すことができます。
これをコールバックで行うことは困難で、しばしばコールバック地獄と呼ばれる厄介なピラミッドになります。
・Promiseのコールバックは、必ずイベントキューに積まれた順番に処理されます。
・エラー処理は旧形式コールバックより遙かに優れています。ピラミッドの各レベルに個別のエラー処理を書く必要がなく、どのレベルでエラーが発生しても最後にあるひとつの.catch()で処理を受け取ることができます。
・コールバックを渡した時点で制御する権利を失う旧形式コールバックと異なり、Promiseは制御の反転を避けることができます。

The nature of asynchronous code

非同期コードの性質をさらに詳しく見てみましょう。
非同期コードの挙動を理解しないまま、非同期コードを同期コードと同じように記述した場合にどのような問題が起こるかを確認します。

以下のコードは、上で出てきたものと似ています。
異なるところは、コードの実行される順番を調べるためにいくつかのconsole.log()が埋め込まれていることです。
実際の動作はこちらで、ソースはこちらで見ることができます。

console.log('Starting');letimage;fetch('coffee.jpg').then((response)=>{console.log('It worked :)')returnresponse.blob();}).then((myBlob)=>{letobjectURL=URL.createObjectURL(myBlob);image=document.createElement('img');image.src=objectURL;document.body.appendChild(image);}).catch((error)=>{console.log('There has been a problem with your fetch operation: '+error.message);});console.log('All done!');

ブラウザがコードを実行すると、まず最初のconsole.log()でStartingを表示し、次にimage変数をセットします。

その後は次の行に進んでfetch()ブロックの実行をはじめますが、fetch()は非同期実行されるため、メイン処理はPromise関連のコードより先に一番最後のconsole.log()まで辿り着き、All done!を出力します。

fetch()ブロックはファイルのフェッチ処理が終了すると、次の.then()ブロックに進み、It worked :)をconsole.log()に出力します。
そのため、このメッセージはあなたが思っていたのと異なる順番で表示されることでしょう。

・Starting
・All done!
・It worked :)

よくわからない場合は、次の小さな例を考えてみてください。

console.log("registering click handler");button.addEventListener('click',()=>{console.log("get click");});console.log("all done");

これは、先ほどの例とよく似た動作をします。
最初と最後のconsole.log()メッセージは即座に表示されますが、2番目のget clickメッセージは、マウスのボタンをクリックするまで表示されません。
Promiseの例では、クリックされるのを待つかわりにリソースの取得が終わるまで待つということになります。

これらのトリビアルな例が示すように、非同期コードは処理順を認識しておかなければ問題を引き起こす可能性があります。
非同期コードブロックは、後で同期コードで使用するために結果を返すようなことはできません。
ブラウザが同期ブロックを処理するより前に、非同期コードが値を返すことを保証しません。

この動作を確認するために、最初の例の3番目のconsole.log()に返り値を入れてみましょう。

console.log('All done! '+image.src+'displayed.');

コンソールには、メッセージではなくエラーが表示されるはずです。

TypeError:imageisundefined;can't access its "src" property

ブラウザが3個目のconsole.log()を実行しようとした時点では、まだfetch()ブロックの動作が完了していないため、imageがまだ定義されていないからです。

注：セキュリティ上の理由から、ローカルのファイルに対してfetch()、もしくは類似の操作を行うことはできません。
上記の例をローカルで再現するためには、ローカルWebサーバを介して実行する必要があります。

Active learning: make it all async!

問題のあるfetch()の例を修正し、3個のconsole.log()が想定したとおりに実行されるためには、3番目のconsole.log()も非同期に実行する必要があります。
これは、2番目のブロックが終わった後に実行されるもうひとつの.then()ブロックを追加するか、あるいは単純に2つめの.then()ブロックの末尾に移動すれば修正できます。
今すぐ試してみてください。

注：行き詰まった場合は、こちらで答えを確認することができます。
あるいはライブに確認できます。
また、後のほうで出てくるGraceful asynchronous programming with Promisesにおいて、Promiseに関するより詳しい情報を知ることができます。

Conclusion

最も基礎的な部分では、JavaScriptは同期・ブロッキング・シングルスレッド言語であり、一度にひとつの動作しか実行することができません。
しかし、Webブラウザは同期実行されない関数を登録する関数およびAPIを提供しています。
そのかわり、これらは何らかのイベントが発生したとき(一定時間経過、ユーザ操作やマウス入力、ネットワーク経由のデータ到着など)に、非同期で呼び出す必要があります。
これらを使うことで、メインスレッドを停止したりブロッキングしたりすることなく、複数の処理を同時に実行させることができるようになります。

コードを同期的に実行するか非同期的に実行するかは、その目的によって決定すべきものです。

対象をすぐにロードして実行したい場合があります。
たとえばユーザ定義スタイルをWebページに適用したい場合、できるかぎり早くスタイルを取り込む必要があるでしょう。

しかし、データベースへのクエリやその結果を使ったテンプレートの作成など、時間のかかる操作を実行する場合は、これをメインスレッドから分離して、非同期にタスクを実行した方がよいでしょう。
時が経つにつれ、この場合は同期ではなく非同期を選択した方が理に叶っていたということがわかります。

In this module

一般的な非同期プログラミングの概念
非同期JavaScriptの紹介
協調型非同期JavaScript:タイムアウトとインターバル
Promiseによる洗練された非同期プログラミング
async/awaitによる簡単な非同期プログラミング
適切な技術を選択する

感想

MDNは、有象無象の氾濫するフロントエンド界隈において、最も信頼できる情報源のひとつです。
わけのわからない変なブログを見るくらいなら、MDNを見た方がよっぽど役に立つことが多いです。
まあ『最も』とか言っちゃうとソースやらW3Cやら見るのが最も適切だって話になるのですが、あんなもの一般人は読んでられませんしね。
あと、たまにMSDN(自動翻訳の混沌)と間違える。

本当はこの記事もMDNにコミットするつもりだったんだけど、構文の変換が想像以上に面倒だったので諦めました。
誰かかわりに送ってやって。

それにしても、ほぼ公式みたいなMDNが未だに訳されてないというのはびっくりですね。

まず問題の翻訳を見てほしい

コーディング規則 - Visual Basic | Microsoft Docs

IsNot キーワードの使用

英語

Use the IsNot keyword instead of Not...Is Nothing.

自動翻訳（誤訳）

IsNot の代わりに Not...Is Nothing キーワードを使用します。

イベント処理

英語

Use Handles rather than AddHandler:

自動翻訳（誤訳）

Handles ではなく AddHandler を使用します。

記事にした経緯

どちらも見事に逆になっているわけです。

上の問題は こちらの記事で参照して気づきました。

下については @tfukumoriさんがフィードバックされています¹。
そしてこちらが Microsoft Localization Team からの回答です。

現在、機械翻訳されたコンテンツに対する翻訳の問題へのコントリビューションはできません。

人間が翻訳したコンテンツに関するフィードバックやご意見をお寄せください。人間が翻訳したコンテンツは機械翻訳エンジンをトレーニングするために使用されているため、お客様は、時間が経つにつれ人間および機械の両方による翻訳の質を向上させることに貢献できます。

人間が翻訳したトピックは、各コンテンツ ファイルのヘッダーの translationtype メタデータ値 "HT" (機械翻訳の場合は "MT") によって、機械翻訳されたトピックと区別できます。

そうですか。

貴重なフィードバックを放置して、何を契機にどんな改善を機械に期待しているのでしょうか。
一度飲み込んで五晩寝たものの、疑念が去らないので記事にしました。

※気になって仕方がないわけでも、怒っているわけでもありません。
　ただ、サイトの影響力の大きさから、（今回の件に限らず）誤った情報が広がってしまうのを心配しています。

つまりこういうことですね？

軍にAI兵士を導入しました。

兵卒「マイクロソフト上官、AI兵士が味方の兵士を次々撃ち殺しています」

MS上官「味方を誤射した兵士がいて、どうも真似しちゃったらしいんだ。誤射した兵士を鋭意教育中だから、そいつが成長してAIが学び直すまで待ってくれ」

ほかの機械翻訳では？

たとえば Google 翻訳はフィードバックを積極に活用しています。

Google 翻訳の改善に協力する - Google Translate ヘルプ
翻訳コミュニティ

最近話題になった悪用の懸念も悩ましいところですが、近年の精度の向上を見るに、一定の成果は上げているのではないかと思います。

今回のような「真逆のこと言ってるじゃん」ということは Google 翻訳でもあるわけですし、将来を見据えた意欲的な試みも歓迎される分野ですから、一概にどちらが優れているとは言えないと思います。

人々の期待

機械翻訳の精度が10年前と比べて格段に上がりました。
それに応じて人々の機械翻訳に対する信頼度も上がっています。
昔よりも信じやすくなっているわけですから、より高いレベルで改善・向上が求められているとも言えます。

本当に機械学習の問題？

ところで今回の件、本当に機械学習の問題でしょうか。

"A instead of B Nothing" ⇒ 「Aの代わりにB」
"A rather than B" ⇒ 「AではなくB」

機械学習がどうこう言うレベルの間違いではない気がします²。
フィードバックをちゃんと読んだのだろうか。

これまたコーディング規約関連で、『型のメンバーの名前』に対する こちらのフィードバックでは、最終的に謝罪、訂正（ここでは「人間翻訳」化）となったわけですが、初動の機械回答感はひどいと言わざるを得ません。
Microsoft コミュニティのモデレータさんも、結構な頻度で同じ匂いのあしらい方をされますよね（こちらは役割が異なるとは思いますが）。
そういった文化、方針なんでしょうか。

機械ではなく人間の問題だと思います。
具体的には、担当部署の姿勢、企業のリソース割り当て（重要度の認識）の問題ではないでしょうか。
機械翻訳に完璧を求めるわけではありませんが、改善に協力しようと真っ当な指摘をした人に対して感謝と敬意を持ち、本当に機械学習の成熟度の問題なのか切り分けたうえで、可能な範囲で真摯に対応する姿勢は見せてほしいです。
というか、もったいないですよね？ こんな凡ミス放置するの。

改元対応の問題でもそうでしたが、日本語ローカライゼーションが重要と位置づけられ、そこに適切なリソースが割り当てられているとはとても思えません。
ちょっと悲しいところです。

自省（頼りすぎ、期待しすぎ）

少し強い表現になってしまったかもしれません³。
意見の偏りもあると思います。

そもそも私が機械翻訳に頼りすぎています。

特に正確さが求められる技術ドキュメントは、できるだけ原語で読むのが原則だと思います。
機械翻訳の精度が上がってきたこともあり、つい便利さに甘えてしまうことが増えました。
英文読解力はみるみる落ちてきました。

これではいかんと、最近はなるべく原語で読むよう（機械翻訳見ちゃったとしても最終的には原語にあたるよう）心がけています。

ということで、本当の問題はここにあったのかもしれません。

書き終えてから Microsoft コミュニティにこんなスレッドを見つけました。

日本語によるフィードバックは、ほぼ無視されているコトが発覚しました。 - マイクロソフト コミュニティ

本国MSでは、日本語のフィードバックを、自動翻訳で英語に訳して読んでいるらしい。

ワレハget_debug_type、コンゴトモヨロシク…

PHPにはプリミティブ型名を取得するgettypeと、オブジェクトのクラス名を返すget_classという関数が存在します。
_があったりなかったりと命名の不統一も気になりますが、それよりgettypeはオブジェクトに使うとobjectしか返さず、get_classをプリミティブ型に使うとE_WARNINGが発生します。
いや、プリミティブ型であればintとかの型が欲しいし、オブジェクトならPDOとかの型が欲しいんだ、という問題に対する答えはありませんでした。

というわけで両者を合体させたget_debug_typeというRFCが提出されました。

PHP RFC: get_debug_type

proposal

このRFCは、指定された変数の型を返す新しい関数、get_debug_typeを追加する提案です。

これは、配列で来る値など、変数の型に基づいた既存のチェック方法では対応できないパターンを置き換えるためのものです。

$bar=$arr['key'];if(!($barinstanceofFoo)){// もっとも単純な例。しかしgettypeは"integer"を返すので、正しい型にしたいなら"int"に変換するなどが必要。thrownewTypeError('Expected '.Foo::class.' got '.(is_object($bar)?get_class($bar):gettype($bar)));}// 今後はこう書けるif(!($barinstanceofFoo)){thrownewTypeError('Expected '.Foo::class.' got '.get_debug_type($bar));}$bar->someFooMethod();

この関数は、正しい型名を返すという点でgettypeと異なります。
"integer"ではなく"int"を返し、クラスもクラス名に変換します。
次の表は、いくつかの値に対してgettypeとget_debug_typeが返す値を比較したものです。

Backward Incompatible Changes

なし。

Proposed PHP Version(s)

PHP8.0

Implementation

https://github.com/php/php-src/pull/5143

投票

投票は2020/03/26まで、2/3の賛成で受理されます。
このRFCは賛成42、反対3で受理されました。

感想

Mark Randallは最初はgettypeがクラス名も返すようにしようとしたものの、Nikitaから「新しい関数にしてくれ」と言われてget_debug_typeを作ったようです。
まあ、これまでobjectとしか言わなかったgettypeがいきなり色々な型を喋り出したら困るところも出そうですからね。

ということで、今後は型の取得はget_debug_typeに一本化できそうです。

手間を省くための定型処理を言語機能に取り込むことは、他の言語でも多々起きていることです。
たとえばJavaScriptのasync/awaitはPromiseの糖衣にすぎず、async/awaitができることは全てPromiseでもできるので、究極的にはasync/awaitは不要です。
しかし非同期処理を楽に書けるようにするために言語仕様に取り込まれました。
糖衣構文の取り込み自体は、このようにさほど珍しいことでもありません。

しかし、str_containsとかis_countableとか、他言語であれば「自分で書け」と言われそうな極端に簡単な構文まで言語仕様に取り込んでしまう言語は、PHP以外にはそうそう無いのいではないかと思います。

PWA？SPA？WebAssembly？
うん、そうだね、よかったね。
それで、そのページは携帯で見れるのかい？

以下はAddy Osmani( Twitter / GitHub / Facebook / HP )による記事、Loading web pages fast on a $20 feature phoneの日本語訳です。
ちなみにこの人はGoogleのエンジニアで、Chromeの開発者のひとりです。

Loading web pages fast on a $20 feature phone

ヒント：高速なWeb基盤を構築することが、低価格のフィーチャーフォンにも、最新のハイエンドスマートフォンにも、全ての人々に良い体験を提供します。

Introduction

20～25ドル未満で購入できるフィーチャーフォンは、発展途上国において数億人が使用しているローエンドデバイスです。
それらはスマートフォンの低性能バージョンとも言えます。

低価格フィーチャーフォンは、CPUの性能が低く(ハイエンドスマホより6倍以上遅い)、RAMが少なく(通常4GB未満で、256-512MBも普通)、ストレージも少なく(4G)、そして大抵はタッチスクリーンもついておらず、ナビゲーションにはキーパッドや十字キーなどを使います。
たとえば以下のようなものです。

これらのデバイスは、ハイエンドスマホのようにリッチJavaScriptやメディアを処理することができません。
そのため、これらに送信するペイロードには特別な注意が必要です。

上記図はGeekbenchによる、2019年上半期に最も売れたスマートフォンのCPUベンチマークです。
人気のフィーチャーフォンであるNokia 3110のパフォーマンスを強調表示しています。

JavaScriptはシングルコアのパフォーマンスが重要であり(Webの他の技術と違い、JavaScriptは本質的にシングルスレッドです)、その性能はCPU性能に依存します。
発展途上国について考えるときは、このデバイス特性に留意する必要があることを意味します。

この記事では、デバイスの性能にかかわらず誰もが利用できるサイトを構築することで、これらの問題に対処していきます。

Background

フィーチャーフォンは、スマートフォンが登場する前、2000年代半ばまで人気のあった端末であることを覚えている人もいるかもしれませんし、覚えていない人もいるかもしれません。
タッチスクリーンではなく小さなキーパッドを備えていて、電話、テキストメッセージ、テキスト中心のシンプルなWebブラウジングなど、かなり基本的な機能でできていました。
スマートフォンの登場後、これらの電話は先進国ではあまり見られなくなりました。

発展途上国では、誰もが4Gネットワークの無制限データプランでスマートフォンを利用できるわけではありません。
この市場は、スマートフォンから最低限の機能を抽出し、ハードウェア性能と価格の妥協の産物、スマートフィーチャーフォンによって成り立っています。

スマートフィーチャーフォン市場は2017年から伸びに伸びており、2019年には世界で4億台ものスマートフィーチャーフォンが販売されると想定されています。

フィーチャーフォンの成長は、3110や8110(Paul Kinlanがデバッグガイドを公開しています)といった往年の名機をNokiaが復活させたことに支えられています。
インドでは、Reliance Jioが外出先でWebにアクセスするための、安価で最新のフィーチャーフォンを提供しています。
JiojはLinuxベースのフィーチャーフォン向けOSであるKaiOSを推進してきました。

フィーチャーフォン市場の成長により、効率的に動作するサイトが必要となってきており、そのためには注意すべき制約がいくつも存在します。

これはGoogle Images LiteとFacebook mBasicのサンプルです。
これらはいずれもフィーチャーフォンで快適に動作するようつくられており、クライアント側のスクリプト依存は最小限です。
ゲームであるProxxはスクリプトに多く依存しますが、フィーチャーフォンでも高速にロードするため積極的なコード分割設計を行っています。

Feature phone constraints

発展途上国のユーザは、3つの要因によって制限されています。
・低価格かつ高性能のデバイスはほとんどない
・高品質なネットワークがない
・手頃な価格のモバイルデータ通信がない

フィーチャーフォン向けサイトが必要であるならば、これらの制約に注意してください。

1. ハードウェア
   フィーチャーフォンは大抵、低速(1.1GHz程度)のシングル・デュアルコアCPUと、512MB未満のRAMでできています。
   この制約が意味するところにおいては、8コアCPUと4GBのRAMでできているiPhone XSと比較してみるとよいでしょう。

2. 通信量
   データプランは安くなりつつありますが、フィーチャーフォンが人気のある地域では依然として大きな制限があります。
   ページが高速に読み込まれ、費用が多くならないように、できるかぎりペイロードを小さくしましょう。

3. スクリーンサイズ
   フィーチャーフォンの画面サイズは通常、スマートフォンのそれよりはるかに小さいです。
   2.4インチの大きさで、ほんの少ししか情報を出すことができません。
   必要なリソースをビューポート内のコンテンツにできるだけ早くロードすることを第一に考えてください。

4. タッチスクリーン
   タッチスクリーンがないので、画面上の各機能、アクションボタン、リンクへはキーパッドから簡単にアクセスできる必要があります。
   必要以上にショートカットキーを埋め込む必要はありません。

5. キーパッド
   フィーチャーフォンのキーパッドは、我々が使い慣れているQWERTYキーボードとは全く異なっています。
   およそ15個のボタンでできていて、多くの文字はボタンを何度も押さなければなりません。
   従って、タイピング量をできるだけ減らすUXを考える必要があります。

日本においても、データプランの上限がユーザエクスペリエンスに影響を与える可能性があります。

In Japan, the web is slower towards the end of the month due to data caps, resulting in reduced engagement pic.twitter.com/rKWClaqWUD

— Yoav Weiss (@yoavweiss) 2019年11月14日

Development Guidelines

以下のTIPSは、フィーチャーフォン向けWebサイトに高速なエクスペリエンスを提供するのに役立つでしょう。
全体的に、ユーザが要求したもの以外のために待たせないでください。
JavaScriptのダウンロード時間と実行時間を可能な限り抑えてください。

Set performance budgets for your initial payloads

良好なパフォーマンスを確保するために開発チームが従わなければならない制限を決める、Performance budgetsという考え方があります。
超過することを許さない制限です。
開発を始める前に定量化可能なメトリックを定義し、新しい機能を追加しても総量が制限を超えないようにします。

Performance budgetsの例としては、JavaScriptのバンドルサイズ、画像のサイズ、HTTPリクエスト数などがあります。
ユーザエクスペリエンスを図るための指標として、First Contentful Paint、Largest Contentful Paint、First Input Delayなどを採用可能です。
対象ユーザに応じて、これらのメトリックごとに閾値を決めていきましょう。

Performance budgetsはアプリケーションロジック、vendorやcommonsのバンドル、そしてその他の項目ごとに設定可能です。
Lighthouseを使ったビルドプロセスや、継続的インテグレーションにおいて強制させることができます。

PRPL-30 - a JavaScript budget for feature phones

Chrome開発チームは、低速ネットワーク上のローエンドデバイスでもなるべく早く操作可能にするため、コード量を細かく制御するPRPLパターンを推奨しています。

PRPLは、ページを表示するために必要な最小限のスクリプトのみをプリロードし、それ以外はあとから遅延ロードし、そしてService Workerで今後のナビゲーション用のデータをキャッシュしておくことを勧めています。

PRPL-50は、イニシャルリソースを50KBに制限するという、Performance budgetsを発展させた考え方です。
フィーチャーフォンはCPUによる制約も受けるため、JavaScriptにさらに厳しい制限を課す必要があります。
フィーチャーフォンを対象とするWebサイトは、PRPL-30(30キロバイト)がよいと考えています。

この仮定においては、SSLネゴシエーションが終わった後、適切なCDNからレスポンスの最初のバイトが返ってくるまでの時間はおよそ2秒です。
従って、初回のペイロードがダウンロードされ、レンダリングされ、ユーザが画面の操作をできるまでの時間は約3秒となります。
すなわち、JavaScript中心のWebサイトの場合は、minifyとgzip圧縮を行った後のバンドルサイズを30キロバイト未満に縮小しなければならないということです。

待って待って。
30キロバイトだって？
ふざけてんの？
Reactのライブラリすら入れることができないんですけど！

厳しい制約のあるデバイス向けのサイトを構築するのであれば、ユーザエクスペリエンスを追求するために難しいトレードオフを行う必要があります。
たとえばReactをサーバ側にしか使わない、あるいはアプリケーションロジックを最小限にして遅延ロードを行わせる、Preactのようなソリューションを使う、などです。
これらのトレードオフについては後で解説します。

PRPL-30を守ることのできるアプリケーションの例としては、たとえば25KBのファイルサイズと5秒未満のインタラクション時間を持つProxxです。
独自の指標を目的とする際は、パフォーマンス予測ツールが役に立つでしょう。

遅延ロードするファイルのサイズも35KB未満が目安です。
30-35KBのチャンクサイズは、V8スクリプトストリーミングが並列処理を行うのに十分な大きさです。

Be Frugal with JavaScript

tl;dr：可能なかぎりスクリプトへの依存を最小限に抑え、静的レンダリングもしくはサーバサイドレンダリングを採用する。
クライアント側レンダリングやハイブリッドレンダリングが必須であれば、必要最小限のスクリプトのみをできるだけ少ない回数リクエストする。
プログレッシブリハイドレーションのようなテクニックも検討する。

JS is the #1 bottleneck on feature phones

フィーチャーフォン向けにインタラクティブな体験を提供する場合、JavaScriptが最大のボトルネックになる可能性が高いことに気を付けてください。
ページをレンダリングする技術の選択によって、ユーザが実際にページを操作できるようになるための時間が遅くなる可能性があるため、この選定は重要です。
サーバサイドレンダリングや静的レンダリングを選んだ場合は、インタラクティブなペイロードはできるかぎり小さくしてください。

JavaScriptにはダウンロード時間および実行時間という、ふたつの大きなコストがあります。
ダウンロード時間は遅いネットワーク(3Gコネクションなど)によって伸び、遅いCPUは実行時間に遅延をもたらします。
下の図は、人気はあるが重いJavaScriptのあるサイトについて、CPUの種類による処理速度の違いを可視化したものです。
ハイエンドのスマートフォンに比べて、ローエンドのスマートフォンでは6倍もの実行時間がかかっていることがわかります。

これは即ち、レンダリングやインタラクティブ性を大きなJavaScriptバンドルに依存しているのであれば、フィーチャーフォンではユーザがUIを操作可能になるまで30から60秒待たされることすらあるということを意味します。

JavaScriptに必要なダウンロード時間と処理時間を最小限に収めるため、開発者はそれらのリソースをできるかぎり節約する必要があり、ユーザが必要とする可能性のあるルートやコンポーネントのためのJavaScriptだけを、それらが必要になったときにロードしなければなりません。

Keep interactive payloads lean

ペイロードを無駄にしないためにも、以下のことを守るべきです。

・画面外にあるコンポーネントやリソース、あるいはファーストビュー内でもクリティカルではないコンテンツについては、できるかぎり遅延ロードします。
・JavaScriptのコードを分割し、ファーストビューで必要なものだけを最初にロードするようにします。これによりダウンロードするスクリプトの量が減り、ページの読み込みが早くなります。
・バンドルから未使用コードを削除し、できるかぎり無駄のない状態にします。そのためにはバンドルを分析し、使用されていないライブラリや一部しか使われていないライブラリを差し替える必要があります。また、最初に使わないライブラリは遅延ロードさせる必要があります。
・差分ロードを用いて、必要な機能のみをブラウザに提供するようにし、過剰なトランスパイルや過剰なポリフィルを避ける必要があります。モダンブラウザに送られるレガシーコードの量を減らすことで、読み込みのパフォーマンスを上げることができます。
・レンダリングや、ファーストビューのUIのためにJavaScriptを使っているのであれば、それらをプリロードしてください。以下のように記述することでそれが重要であることをブラウザに伝えることができ、ブラウザはできるだけ早くロードします。

<linkrel="preload"as="script"href="critical.js">‬

Choose your stack wisely

サードパーティ製ライブラリは開発を高速化し、複雑なタスクを容易に実現することに役立ちますが、その対価として重くなりがちです。
フィーチャーフォン向けに開発する場合は使用に注意しなければなりません。
以下のガイダンスを参考にしてください。

・フィーチャーフォンはリソースに大きな制約があるため、可能ならばJavaScriptフレームワークの使用そのものを避けるか、できるかぎり制限してください。
JavaScriptフレームワークは多大なオーバーヘッドを要求します。
Reactを使うのであればサーバサイドレンダリングするか、あるいはビルド時にPreact compatを使ってPreactに入れ替えて30キロバイト削減する、などの代替を検討してください。
Svelte、lit-html、そしてVanilla JSなどはバンドルを軽くするための良い選択肢です。

・サードパーティライブラリへの依存をできるかぎり減らし、初期ロードに必要なバンドルサイズを削減してください。たとえばMoment.jsのかわりにdate-fnsやluxonを使うなどです。bundlephobia.comなどでサイズのチェックができます。

・状態管理のためにReduxやStoreを使う場合は厳重な注意が必要です。
StateがしばしばHTMLにインライン展開され、レスポンスサイズが非常に大きくなってしまうことがあります。

Adapt to avoid loading heavy resources on slow connections

ヒント：このトピックの詳細については、adaptive loading - improving web performance on low-end devicesを参照してください。

Adaptive Loadingとは、提供するリソースをeffectiveTypeに基づいて変更する技術で、ブラウザからはNetwork Information APIで利用可能です。
Adaptive servingを使うことで、低速なユーザにも低機能であってもひとまずのエクスペリエンスを提供することが可能になります。

console.log(navigator.connection.effectiveType);// 3G

注意：たとえeffectiveTypeが"4G"であっても、スタバやカンファレンス会場のWifiのように実速度は低速である可能性は十分にあります。

Adaptive servingを使用すべき具体的な例としては、製品紹介ページなどがあります。
接続速度の遅いユーザには圧縮された商品画像だけを、高速なユーザには高品質な画像とJavaScriptによる強化された演出(画像のズームインや、別製品との比較を表示する機能など)を提供したりすることができるでしょう。

フィーチャーフォンにおいては、低速な回線が必ずしも最大の障害であるとは限りません。
遅いCPUや少ないメモリは、回線種別より多くの影響をユーザ体験に与えます。
Client Hintsは、CPUの性能にこそアクセスできないものの、デバイスのメモリ、Viewportの幅、ピクセルレート、ネットワーク情報、そしてその他の情報を集めることで、より詳細なサービス戦略を立てるために使うことができます。

Be respectful of users data plans with the Save-Data header

Android版Chromeにはライトモード(Data Saver)と呼ばれる機能があり、通信量を気にするユーザは、ブラウザがリソースを最適化してページの読み込み速度を向上させるオプションを選ぶことができます。
最適化には、画像を圧縮したり、重要でないリソースを後回しにしたり、ページをサーバ側でレンダリングすることなどが含まれています。
詳しくはChrome Lite Pagesをご覧ください。

対応しているブラウザでユーザがデータ節約モードを選択すると、あらゆるHTTP/HTTPSリクエストにSave-Dataリクエストヘッダが
アプリケーション開発者は、このヘッダがあれば重い機能をオフにするなど、データ節約モードをオンにしているユーザに最適化された体験を提供することができます。
JavaScriptでは以下のスニペットで確認可能です。

if("connection"innavigator){if(navigator.connection.saveData===true){// Implement data saving operations here.}}

注意：お使いのフィーチャーフォンはChromeをサポートしているかもしれませんが、お使いのChromeがライトモードをサポートしているとは限りません。

Offload costly app logic and state handling to Web Workers

SurmaによるTechniques to make a web app load fast, even on a feature phoneを読んでください。
素晴らしい投稿です。

ブラウザのメインスレッドでは、JavaScript以外にもページレイアウト、ピクセルの描画、ユーザインタラクションの追跡など多くの機能が動いています。
複雑で時間のかかるJavaScriptは、これら他のタスクをブロックしてしまう可能性があります。

Web Workersは、メインスレッドをブロックせずにバックグラウンドでJavaScriptを実行できる技術です。
複雑なアプリロジックや状態管理サービスなど、コストのかかるJavaScriptのオーバーヘッドをメインスレッドから切り離すことができます。
メインスレッドとワーカースレッドは、postMessage()とonmessageハンドラでやりとりできます。
postMessageを使って、任意の値やオブジェクトを含むひとつの値を送り付けることができます。
実装の困難はComlinkのようなライブラリで軽減することができます。

ワーカースレッドを使った場合と使わなかった場合でProxxの差を調べた、Surmaのケーススタディは読みごたえがあります。
Nokia2(RAM1GB、1.3GHzクアッドコア)では、ワーカースレッドを使わなければ6.6秒もの間アプリがフリーズしました。
しかし、ワーカースレッドを使った場合は、応答するまでの時間は48ミリ秒でした。
CPUをごりごり使う処理を書いているのであれば、それをワーカースレッドに移植する価値は十分にあると言っていいでしょう。

Optimize Images

画像は多くのデータ量を消費します。
低価格デバイスでは特に、デコードにも時間がかかります。
従ってフィーチャーフォンに画像を配信する際は、適切に画像のサイズと圧縮方法を選ぶことが大事です。

・Imageminのようなツールを使って、品質を下げずに画像のサイズを削減します。
・アニメーションGIFは動画に変換しましょう。ロードがはるかに速くなります。しかしその前に、ローエンドデバイスがそんなに重いメディアファイルを必要としているか考えてください。
・可能なら画像を遅延ロードしますが、遅延ロードさせるJavaScriptライブラリが重くては意味がありません。ネイティブのloading属性が役立つでしょう。
・同じ画像を複数のサイズで用意しておき、ユーザのviewportに最も適したものを選択して提供するレスポンシブイメージが役立ちます。
・画面に合った画像を提供します。低解像度のローエンドデバイスにはそれなりの画像を送ることで、より高速にデコードを行うことができます。

Detecting screen-size

現在は多くのスマホがQVGAで、解像度は320px * 240pxとなっています。
機能のオンオフやアダプティブローディングを画面サイズによって切り替えたい場合、以下のようなスニペットを使うことができます。

constisFeaturePhone=Math.min(screen.width,screen.height)<=240;

これは、Porxxが採用しているアプローチに似た方法です。

Emulate a feature phone in Chrome DevTools

低価格フィーチャーフォン向けサイトを構築するのであれば、格安端末の実物を入手することを強くお勧めします。

PSA: if you like to test if your website works on KaiOS & if you live in US, a trip to BestBuy and $15 will get you this device for testing. pic.twitter.com/M4qbcgmtB3

— Mariko Kosaka (@kosamari) 2019年5月13日

Chrome DevToolsでフィーチャーフォンをエミュレートするのであれば、以下の手順で可能です。

・Chrome DevToolsを開く
・Toggle Device Toolbarを選択
・デバイスのドロップダウンからEdit→Add custom deviceを選択
・名前をKaiOS(もしくは必要な対象名)にする
・幅240、高さ320を指定
・UAをMozilla/5.0 (Mobile; LYF/F90M/LYF-F90M-000-02-23-181217; Android; rv:48.0) Gecko/48.0 Firefox/48.0 KAIOS/2.5 YouTube/1.66.51.Jにする
・保存する
・(オプション)CPU性能をカスタマイズすることもできますが、これはあまり正確ではありません

Conclusion

何処にいる誰にでも、全てのユーザに楽しい体験を提供することは可能です。
ただし、全てのユーザのハードウェアが同じではないので、その点には注意が必要です。

端末の価格が手頃であるほど、CPUの性能も同等に低い可能性が高まります。
JavaScriptのパフォーマンスがダウンロード時間と実行時間に依存していることを考慮し、適切なエクスペリエンスを提供することを考えてください。

これはスマートフォンでも注意すべき点ですが、フィーチャーフォンではさらに重要になります。

コメント欄

「すごい有意義な投稿だった！」
「よく見たらChromeの中の人じゃん。有益な情報をありがとう」
「Svelteのパフォーマンスが高いと感じていたので言及してくれてうれしい。Preact試してみる！」「SvelteとSapperが大好き！」「Svelteや類似のフレームワークが早く普及してほしいね」
「バンドルサイズを抑える最も簡単な方法？簡単さ、JavaScriptを使わなければいい。」

感想

JavaScriptなんてほぼ動かないからHTML全部べた書きな、CSSもまともに効かないからfontタグを使え、とかそういうレベルの話かと思っていたら全然違っていて、わりと最近のAndroidフィーチャーフォンの話だった。
JavaScriptもCSSもきちんと認識してくれるけど、単に性能が低くてネットワークも遅いから、そういうところでも見れるように出力をカスタマイズしろ、という話ですね。

日本ではローエンドと言われているデバイス、安価な通信回線でも一般的なWebサイトを見るには十分な能力を持っているため、日本向けのWebサイトであれば正直そこまで気にする必要はありません。
しかし、たとえば日本では完全に無名のTranssionは、アフリカに特化したフィーチャーフォンを作って2000円で毎年1億台売っています。
アフリカは次の中国と期待される未知の市場です。
2000円の超ローエンドデバイスでも快適に見られるWebサイト作りが、世界に目を向けるならば必要となってくることでしょう。

ともあれ、ローエンドだろうがハイエンドだろうが無駄にアニメーションとスクロールを要求するサイトは滅ぶべきである。

throw expressionというRFCが投票中です。

最初のアイデアは2019/12/06のSebastiaan Andewegによるツイート。

Really liking the arrow functions in PHP 7.4 so far! Unfortunately already found one missing feature: you can't throw Exceptions from them. The following results in a 'unexpected T_THROW' syntax error:

fn() => throw new Exception('nope');

Would've cleaned up my test, but alas.

— Sebastiaan Andeweg (@sebandeweg) 2019年12月5日

それに対して2020/03/19にCarusoが反応し、そしてその日のうちにiluuu1994が最初のプルリクを出しました。
はえーよ。

throw expression

Introduction

PHPのthrowは文であるため、アロー関数や三項演算子、NULL合体演算子などの式しか許されない場所から例外を投げることができません。
このRFCでは、それらを可能にするためthrow文を式に変更することを提案します。

Proposal

式を記述可能なあらゆるコンテキストでthrowが利用可能になります。
以下は思いついた便利そうな例です。

// アロー関数$callable=fn()=>thrownewException();// nullチェック$value=$nullableValue??thrownewInvalidArgumentException();// trueっぽいチェック$value=$falsableValue?:thrownewInvalidArgumentException();// 空ではない配列チェック$value=!empty($array)?reset($array):thrownewInvalidArgumentException();

他にも、議論の余地のある使用方法があります。
このRFCでは、以下のような記述も許可されています。

// ifを使った方が意図が明確になる$condition&&thrownewException();$condition||thrownewException();$conditionandthrownewException();$conditionorthrownewException();

Operator precedence

throwが式になると、優先順位を決める必要があります。
以下は現時点で有効な書式の例です。

throw$this->createNotFoundException();// こうなるthrow($this->createNotFoundException());// こうではない(throw$this)->createNotFoundException();throwstatic::createNotFoundException();// こうなるthrow(static::createNotFoundException());// こうではない(throwstatic)::createNotFoundException();throw$userIsAuthorized?newForbiddenException():newUnauthorizedException();// こうなるthrow($userIsAuthorized?newForbiddenException():newUnauthorizedException());// こうではない(throw$userIsAuthorized)?newForbiddenException():newUnauthorizedException();throw$maybeNullException??newException();// こうなるthrow($maybeNullException??newException());// こうではない(throw$maybeNullException)??newException();throw$exception=newException();// こうなるthrow($exception=newException());// こうではない(throw$exception)=newException();throw$exception??=newException();// こうなるthrow($exception??=newException());// こうではない(throw$exception)??=newException();throw$condition1&&$condition2?newException1():newException2();// こうなるthrow($condition1&&$condition2?newException1():newException2());// こうではない(throw$condition1)&&$condition2?newException1():newException2();

共通して言えるのは、全てがthrowキーワードより高い優先順位を持つということです。
このため、このRFCではthrowキーワードの優先順位を可能な限り低くすることを提案します。
現在有効なコードは、たとえ直感に反する動作だったとしても、今後も同じ動作をし続けます。
なぜなら、一般的にthrowは最後に使用するべき演算子であり、それ以降に記述した式は評価されないからです。

低い優先順位の唯一の欠点は、短絡評価のために括弧が必須になることです。

$condition||thrownewException('$condition must be truthy')&&$condition2||thrownewException('$condition2 must be truthy');// こうなる$condition||(thrownewException('$condition must be truthy')&&$condition2||(thrownewException('$condition2 must be truthy')));// こうではない$condition||(thrownewException('$condition must be truthy'))&&$condition2||(thrownewException('$condition2 must be truthy'));

もっとも、こんなコードはほぼ使われていないでしょう。

Backward Incompatible Changes

後方互換性のない変更はありません。

Other languages

C#では同じ文法が2017年に実装されました。

このような言語は他にはあまりありません。
ECMAScriptにプロポーザルがありますが、これは同じ問題を抱えているからです。

Proposed PHP Version(s)

PHP8。

投票

投票は2020/04/19まで、2/3の賛成で受理されます。
2020/04/06時点では賛成14、反対1で、受理される見込みです。

過去のML

9年前とか15年前にも同じ発想があったようですが、そのときは立ち消えになりました。
当時とはPHPのおかれた環境やRFCの出し方などがだいぶ異なることと、そしてなにより実物のプルリクがあるというのは大きいでしょう。

感想

ややこしいよね文と式。
全てが式になればいいのに。

というわけで、今後はもっと気軽にthrowすることができるようになります。
それどころかアロー関数で引数によって値を返したり例外Aを出したり例外Bを出したりすることもできちゃいますよ。
まあ正直、throwを出すようなややこしい式をアロー関数に書くんじゃないよと思ったりはするわけですが。

PHPのソースを眺めていたら、先日2020/04/07にNikitaがなんか面白そうなプルリクを出していました。
Named Parametersという2013年に提出されたまま忘れ去られたRFCがあるのですが、その機能を実装したものです。

どういう機能ってこういうのです。

functionhoge($foo,$bar){echo"foo=$foo,  bar=$bar";}hoge(bar=1,foo=2);// foo=2, bar=1

PythonやCSharpなんかで実装されてるやつですね。

Nikita本人は機能が幾つも不足しているよと言っているのですが、不足の内容はOpcache対応や引数アンパックといった周辺機能で、基本的な機能は既に実装されているみたいです。

PHP RFC: Named Parameters

State of this RFC

これは名前付き引数についての準備的なRFCです。
このRFCの目的は、次のPHPバージョンで名前付き引数をサポートすべきか、またサポートするときはどのように実装すべきかを確認することです。
ここで解説している構文や動作は最終的なものではなく、詳細を詰めていく必要があります。

このRFCの実装はまだ完全なものではありません。
これは非常に複雑な機能なので、この機能が必要でなかったのに時間をかけて実装したくはありません。

Update 22-05-2014

私は他のことで忙しく、このRFCには取り組めていません。
このRFCはPHP6に間に合うように復活させるつもりです。
それまでの間、未解決の問題に対する議論の結果の一部をここにまとめておきます。

・名前付き引数のコンセンサスはまだ得られていません。
・名前付き引数のアンパックと、名前のない引数のアンパックは...構文に統合されます。アンパックのRFCは既に決定しているため、ここについて選択肢はあまりありません。
・継承時のパラメータ名チェックは強制されません。これはあまりにも大きなBC breakになるとはんだんされました。

主な未解決の実装上の問題は"Patch"セクションにリストアップされています。

What are named arguments?

名前付き引数とは、パラメータの順番ではなくパラメータ名を使って関数に引数を渡す方法です。

// 通常の引数array_fill(0,100,42);// 名前付き引数array_fill(start_index=>0,num=>100,value=>42);

名前付き引数に渡す引数の順番は自由です。
上記例では関数シグネチャと同じ順番で引数を渡していましたが、異なる順番で渡すこともできます。

array_fill(value=>42,num=>100,start_index=>0);

名前付き引数と名前のない引数を組み合わせることも可能であり、オプション引数の一部のみを名前付き引数で渡すことも可能になります。

htmlspecialchars($string,double_encode=>false);// ↓と同じhtmlspecialchars($string,ENT_COMPAT|ENT_HTML401,'UTF-8',false);

What are the benefits of named arguments?

名前付き引数の明白な利点の一つは、上のコードサンプルを見ればわかります。
変更したい引数までの間にある引数に対して、それぞれデフォルト値を指定する必要から解放されます。
名前付き引数があれば、変更したい引数だけを直接指定することができます。

これはデフォルト引数のRFCでも可能ですが、名前付き引数を使えば意図がより明白になります。
構文を比較してみてください。

htmlspecialchars($string,default,default,false);// vshtmlspecialchars($string,double_encode=>false);

ひとつめのコードを見ても、たまたまhtmlspecialcharsの引数を丸暗記していないかぎりfalseが何を意味するのかは分からないでしょう。

コードの自己文書化の利点は、オプション引数をスキップしないときにおいても明らかです。

$str->contains("foo",true);// vs$str->contains("foo",caseInsensitive=>true);

名前付き引数を使うことで、新しい方法で関数を使うことができるようにbなります。
引数を順番に並んだリストとしてだけではなく、キーと値のペアのリストとしても扱えるということです。
以下のような使い方が考えられます。

// 現在の構文$db->query('SELECT * from users where firstName = ? AND lastName = ? AND age > ?',$firstName,$lastName,$minAge);// 名前付き引数$db->query('SELECT * from users where firstName = :firstName AND lastName = :lastName AND age > :minAge',firstName=>$firstName,lastName=>$lastName,minAge=>$minAge);

Implementation

Internally

名前付き引数は、他の引数と同じくVM stackを通して渡されます。
これらの引数の違いは、位置引数は常にスタックの先頭に渡されるのに対し、名前付き引数は任意の順番でスタックに挿入することができるということです。
使用されないスタックの位置にはNULLが入り、引数カウントはNULLも数えます。

Errors

位置引数と名前付き引数を混在させることが可能ですが、名前付き引数は位置引数の後に配置しなければなりません。
そうしなければコンパイルエラーが発生します。

strpos(haystack=>"foobar","bar");// Fatal error: Cannot pass positional arguments after named arguments

可変長引数ではない関数に存在しない引数名を渡した場合、致命的エラーが発生します。

strpos(hasytack=>"foobar",needle=>"bar");// Fatal error: Unknown named argument $hasytack

同じ名前の引数を複数回渡した場合、新しい方で古い方が上書きされ、警告が発生します。

functiontest($a,$b){var_dump($a,$b);}test(1,1,a=>2);// 2, 1// Warning: Overwriting already passed parameter 1 ($a)test(a=>1,b=>1,a=>2);// 2, 1// Warning: Overwriting already passed parameter 1 ($a)

Collecting unknown named arguments

可変長引数の...$args構文を使った場合、余った名前付き引数は$argsに集められます。
名前付き引数は常に位置引数より後ろとなり、渡された順番が保持されます。

functiontest(...$args){var_dump($args);}test(1,2,3,a=>'a',b=>'b');// [1, 2, 3, "a" => "a", "b" => "b"]

使用例としては前述の$db->query()があります。

これはPythonで**kwargsと呼ばれている機能です。

Unpacking named arguments

引数アンパックのRFCは名前付き引数のアンパックにも対応します。

$params=['needle'=>'bar','haystack'=>'barfoobar','offset'=>3];strpos(...$params);// int(6)

文字列キーを持つ任意の値は、名前付きパラメータとして展開されます。
それ以外のキーは通常の位置引数として扱われます。

位置引数と名前付き引数をひとつの配列にまとめることも可能ですが、その場合でも引数の順番は守らなければなりません。
名前付き引数より後に位置引数が出てきた場合は警告がスローされ、アンパックは中止されます。

func_* and call_user_func_array

名前付き引数を使って、スタックから引数としてNULLが渡ってきた場合、func_*関数の挙動は以下のようになります。

・func_num_args()はNULLを含んだ引数の個数を返す。
・func_get_arg($n)はデフォルト値を返す。デフォルト値がない場合はNULL。
・func_get_args()はデフォルト値を返す。デフォルト値がない場合はNULL。

3関数とも、未定義の引数名は無視します。
func_get_argsは値を返さず、func_num_argsはカウントに含めません。

call_user_func_arrayは名前付き引数をサポートしません。
文字列キーを持つ配列を渡すコードが壊れるからです。

Open questions

Syntax

現在の実装および提案では、名前付き引数について以下2種類の構文をサポートしています。

test(foo=>"oof",bar=>"rab");test("foo"=>"oof","bar"=>"rab");

ふたつめの構文は、引数名が予約語である場合のためにサポートされています。

test(array=>[1,2,3]);// syntax errortest("array"=>[1,2,3]);// works

この構文の選択は恣意的なもので、特に深く考えずに採用しました。
以下に、いくつか代替構文の提案があります(ほとんどはPhil Sturgeonによる提案です)。

// currently implemented:test(foo=>"oof",bar=>"rab");test("foo"=>"oof","bar"=>"rab");// キーワードを使えるtest($foo=>"oof",$bar=>"rab");test(:foo=>"oof",:bar=>"rab");test($foo:"oof",$bar:"rab");// キーワードを使えないtest(foo="oof",bar="rab");test(foo:"oof",bar:"rab");// 既に有効なコードなので不可test($foo="oof",$bar="rab");

どの構文で決定するかは議論次第です。

Collection of unknown named args into ...$opts

現在のRFCでは、位置引数と名前付き引数の両方がまとめて可変長引数の...$optsに入ってきます。
Pythonでは前者を*argsに、後者を**kwargsに入れるというアプローチをとっています。

Pros：PHPでは、Pythonではできない配列と辞書の混在ができます。
Cons：位置引数と名前付き引数を別にすることで、意図がより明確になります。必ずしも両方の引数をサポートしたいとはかぎらず、片方だけを強制したいかもしれません。

どのように扱うのが適切か、意見や議論を歓迎します。

Unpacking named args

引数アンパックについても同じ疑問が出てきます。
...$fooは位置引数と名前付き引数を一緒にできますが、*$fooと**$fooに分けるべきでしょうか。

この決定は、可変長引数と同じに揃えるべきでしょう。

Signature validation allows changing parameter names

現在のところ、引数名はシグネチャに含まれていません。
位置引数しか使わない場合、これは合理的です。
引数名は関数の呼び出しに関係ないからです。

名前付き引数はこの動作を変更します。
継承先クラスが引数名を変更した場合、名前付き引数を使った呼び出しは失敗し、LSPに違反します。

interfaceA{publicfunctiontest($foo,$bar);}classBimplementsA{publicfunctiontest($a,$b){}}$obj=newB;// Pass params according to A::test() contract$obj->test(foo=>"foo",bar=>"bar");// ERROR!

名前付き引数が導入された場合、シグネチャの検証において引数名の変更にエラーを出さなければなりません。
通常の場合、インターフェイスと実装クラスの不一致は致命的エラーを発生させますが、名前付き引数において致命的エラーを出すとBC breakが大きくなりすぎてしまいます。
かわりに、より低いエラータイプ(WARNING / NOTICE / STRICT)を出すことを検討します。

これに関する具体的な議論のポイントをひとつ挙げておきます。
PHPは、実行時の動作を変更するini設定を導入する習慣を過去に置いてきました。
従って、この挙動をiniで制御できるようにすることは、私の選択肢にはありません。

Patch

差分がこちらにありますが、このパッチは不完全で、ダーティで、既知のバグがあります。

やるべき作業はまだまだ残っています。

・"Open questions"の結果を実装する。
・内部関数の全てのarginfosをドキュメントと一致するように更新する。現在のarginfo構造体は絶望的に時代遅れで、引数割り当てなどは自動的にできるようにしたい。
・内部関数において引数がスキップされたときに適切に動作するようにする。ほとんどの場合は自動的に動作するはずだが、手動調整が必要になる関数もかなりあるだろう。

感想

2014年とかPHP6とか出てくることからわかるように、このRFCはだいぶ昔に書かれてそのまんまです。
当時作成されたパッチはもはや使い物にならないため、新たにプルリクを作ってきたようです。
パッチにしろその他の内容にしろ、当時のPHPと今のPHPはだいぶ異なったものになっているので、なんにしろRFCのリファインは必要になるでしょう。

このプルリクについても、とりあえず提出されただけで何の展開もありませんし、メーリングリストでの議論も特に進んでいるわけではありません。
従って、このプルリクも今後どうなるかはわからず、再びこのまま忘れ去られるかもしれません。
しかしNikitaのことですから、いきなり完動品のプルリクが送られてきて第一線に躍り出る、なんてことがあっても驚きはないですね。

混沌の時代に実装された関数などでは特に、同じ内容の関数でも引数の順番が異なったりしていて大変なのですが、この機能が実装されたら、そのあたりを楽に処理できるようになります。
また却下されたデフォルト引数のRFCも、この名前付き引数があれば不要になります。
絶対にないといけないというほどでもないですが、存在すれば純粋に便利になる、そんな良い機能だと思います。

あとここからは完全に妄想ですが、このプルリクはジェネリクスへの足掛かりなのではないかと感じています。
Nikitaはどうもジェネリクス大好きっ子みたいですから、このプルリクを元に引数まわりに手を付けて、ついでにジェネリクスまでできるようにちゃったぜみたいなことを考えているのではないでしょうか。

本記事はModern Best Practices for Testing in Javaの日本語訳です。元記事の著者から許可を得て翻訳、公開しています。
翻訳は不慣れなので変なところもあると思いますが、ご容赦ください。

メンテナンスしやすくて読みやすいテストコードは良いテストカバレッジを確立するために重要で、それにより何かを壊すことを恐れずに新機能の実装やリファクタリングが可能になります。この記事には、私がJavaでユニットテストや統合テストを長年に渡って書いて得られた多くのベストプラクティスが含まれています。それにはJUnit5やAssertJ、Testcontainers、Kotlinといったモダンな技術も含みます。中には当たり前と思われるようなこともあるかもしれませんし、あなたがソフトウェア開発やテストについての本で読んだことと相容れないこともあるかもしれません。

TL;DR

• ヘルパー関数やパラメータ化テスト、AssertJの強力なアサーションを多用し、変数を使いすぎず、関連することだけを検証し、滅多に起こらないようなケースに対してテストを書くことを避けることで、小さくて明確なテストを書きましょう。

• 全ての関連があるパラメータを明確にし、データを正しく挿入し、継承よりもコンポジションを使うことで、自己完結しているテストを書きましょう。

• 本番コードの再利用を避け、出力値とハードコードされた値との比較に焦点を当てることで、ダンプテスト¹を書きましょう。

• KISSの原則 > DRY原則

• 完全な垂直スライドをテストする²ことに焦点を当て、インメモリデータベースの使用を避けて、本番環境に近いテストを書きましょう。

• JUnit5とAssertJはとても良い選択です。

• staticなアクセスを避け、コンストラクタインジェクションを使い、 Clock³を使い、非同期実行からビジネスロジックを分離することで、テストしやすい実装になるように労力を費やしましょう。

  基本

  Given, When, Then

  テストは、1行の空行で分けられた3つのブロックで構成されるべきです。コードのそれぞれのブロックはできるだけ短くするべきです。ブロックを短くするためにサブ関数を使いましょう。

• Given(入力): データの生成やモックの設定のようなテストの準備

• When(実行): テスト対象のメソッドや動作の呼び出し

• Then(出力): 出力や振る舞いが正しいかどうか検証するためのアサーションの実行

// 良い例@TestpublicvoidfindProduct(){insertIntoDatabase(newProduct(100,"Smartphone"));Productproduct=dao.findProduct(100);assertThat(product.getName()).isEqualTo("Smartphone");}

“actual*” と “expected*” のプレフィックスを使う

// 悪い例ProductDTOproduct1=requestProduct(1);ProductDTOproduct2=newProductDTO("1",List.of(State.ACTIVE,State.REJECTED))assertThat(product1).isEqualTo(product2);

同じ値かどうかのアサーションで変数を使うなら、変数名のプレフィックスとして"actual” や “expected” を付けましょう。これによって読みやすくなり、変数の意図が明確になります。その上、期待値と実測値を混同してしまう恐れが減ります。

// 良い例ProductDTOactualProduct=requestProduct(1);ProductDTOexpectedProduct=newProductDTO("1",List.of(State.ACTIVE,State.REJECTED))assertThat(actualProduct).isEqualTo(expectedProduct);// 素晴らしくて明確

ランダム性のある値よりも固定値を使う

ランダム性のある値はテストを不安定にし、デバッグが困難になり、エラーメッセージが省略され、コードへのエラーの追跡が困難になるため避けましょう。

// 悪い例Instantts1=Instant.now();// 1557582788Instantts2=ts1.plusSeconds(1);// 1557582789intrandomAmount=newRandom().nextInt(500);// 232UUIDuuid=UUID.randomUUID();// d5d1f61b-0a8b-42be-b05a-bd458bb563ad

代わりに、全てに対して固定値を使用しましょう。固定値はテストの再現性を高くし、デバッグを容易にし、関連するコードの行への追跡を容易にするエラーメッセージが出力されます。

// 良い例Instantts1=Instant.ofEpochSecond(1550000001);Instantts2=Instant.ofEpochSecond(1550000002);intamount=50;UUIDuuid=UUID.fromString("00000000-000-0000-0000-000000000001");

ヘルパー関数を使用することで、タイピング量を減らすことができます。

小さくて明確なテストを書く

ヘルパー関数を多用する

細かいコードや繰り返し出現するコードをサブ関数に抽出し、それに説明的な名前をつけましょう。それはテストを短く保ち、テストの要点が一目で簡単に把握できるようになるという意味で強力です。

// 悪い例@TestpublicvoidcategoryQueryParameter()throwsException{List<ProductEntity>products=List.of(newProductEntity().setId("1").setName("Envelope").setCategory("Office").setDescription("An Envelope").setStockAmount(1),newProductEntity().setId("2").setName("Pen").setCategory("Office").setDescription("A Pen").setStockAmount(1),newProductEntity().setId("3").setName("Notebook").setCategory("Hardware").setDescription("A Notebook").setStockAmount(2));for(ProductEntityproduct:products){template.execute(createSqlInsertStatement(product));}StringresponseJson=client.perform(get("/products?category=Office")).andExpect(status().is(200)).andReturn().getResponse().getContentAsString();assertThat(toDTOs(responseJson)).extracting(ProductDTO::getId).containsOnly("1","2");}

// 良い例@TestpublicvoidcategoryQueryParameter2()throwsException{insertIntoDatabase(createProductWithCategory("1","Office"),createProductWithCategory("2","Office"),createProductWithCategory("3","Hardware"));StringresponseJson=requestProductsByCategory("Office");assertThat(toDTOs(responseJson)).extracting(ProductDTO::getId).containsOnly("1","2");}

• データ（オブジェクト）の生成のため（ createProductWithCategory()）と、複雑なアサーションのためにヘルパー関数を使ってください。ヘルパー関数には、テストに関係のあるパラメータのみを渡すようにします。それ以外の値については、適切なデフォルト値を使ってください。Kotlinでは、デフォルト引数を使うことで簡単に実現できます。Javaでは、擬似的なデフォルト引数を実現するためにメソッドチェーンとオーバーロードを使う必要があります
• 可変長引数はテストコードをより簡潔にしてくれます（ ìnsertIntoDatabase()）
• ヘルパー関数はシンプルな値をより簡単に生成するためにも使えます。拡張関数を使うことができるKotlinなら、よりやりやすいです。

// 良い例 (Java)Instantts=toInstant(1);// Instant.ofEpochSecond(1550000001)UUIDid=toUUID(1);// UUID.fromString("00000000-0000-0000-a000-000000000001")

// 良い例 (Kotlin)valts=1.toInstant()valid=1.toUUID()

このヘルパー関数はKotlinではこのように実装します:

funInt.toInstant():Instant=Instant.ofEpochSecond(this.toLong())funInt.toUUID():UUID=UUID.fromString("00000000-0000-0000-a000-${this.toString().padStart(11, '0')}")

変数を使い過ぎない

複数回使われている値を変数に抽出することは、開発者の常用手段です。

// 悪い例@Testpublicvoidvariables()throwsException{StringrelevantCategory="Office";Stringid1="4243";Stringid2="1123";Stringid3="9213";StringirrelevantCategory="Hardware";insertIntoDatabase(createProductWithCategory(id1,relevantCategory),createProductWithCategory(id2,relevantCategory),createProductWithCategory(id3,irrelevantCategory));StringresponseJson=requestProductsByCategory(relevantCategory);assertThat(toDTOs(responseJson)).extracting(ProductDTO::getId).containsOnly(id1,id2);}

不幸にも、これはテストコードを著しく膨張させます。その上、得られるテスト失敗メッセージから、関連するコード行にさかのぼって値を追跡することは難しいです。

KISSの原則 > DRY原則

// 良い例@Testpublicvoidvariables()throwsException{insertIntoDatabase(createProductWithCategory("4243","Office"),createProductWithCategory("1123","Office"),createProductWithCategory("9213","Hardware"));StringresponseJson=requestProductsByCategory("Office");assertThat(toDTOs(responseJson)).extracting(ProductDTO::getId).containsOnly("4243","1123");}

テストコードが短く保たれていれば（それは強く推奨されます）、同じ値がどこで使われているのか知るのに何の支障もありません。それに加え、メソッドはさらに短くなり、それゆえに理解が容易です。そして最後に、この場合の失敗メッセージは、コードをさかのぼって追跡することをより簡単にしてくれます。

既存のテストを「ただもう一つ小さなことをテストするだけ」のために拡張しない

// 悪い例publicclassProductControllerTest{@TestpublicvoidhappyPath(){// 大量のコードがここに...}}

滅多に起こらないケースのテストを既存の（ハッピーパス⁴の）テストに追加することは魅惑的です。
しかし、そのテストは大きくて理解が難しいものになります。それは、その大きなテストによってカバーされる全ての関連するテストケースを把握することを困難にします。一般的に、こういったテストは「ハッピーパステスト」と呼ばれます⁵。
もしこのようなテストが失敗した時、何が壊れたのか正確に理解するのは難しいです。

// 良い例publicclassProductControllerTest{@TestpublicvoidmultipleProductsAreReturned(){}@TestpublicvoidallProductValuesAreReturned(){}@TestpublicvoidfilterByCategory(){}@TestpublicvoidfilterByDateCreated(){}}

代わりに、期待する振る舞いについて全てわかる説明的な名前を持った新しいテストメソッドを作りましょう。はい、書く量は増えますが、関連する振る舞いだけをテストする、目的にぴったり合った明確なテストを作ることができます。繰り返しますが、ヘルパー関数はタイピング量を減らします。そして最後に、説明的な名前を持った、目的にぴったり合ったテストを追加することは、実装された振る舞いを記録する方法としてとても良いです。

テストしたいことだけをアサートする

本当にテストしたいことは何かということについて考えましょう。できるからといって、必要以上にアサートすることを避けましょう。さらに、前のテストにおいて既にテストしたことについて心に留めましょう。通常は、全てのテストにおいて同じことを何度もアサートする必要はありません。これによってテストが短く保たれ、明確に示され、期待する振る舞いについて気をそらされることがありません。

例について考えてみましょう。製品情報を返すHTTPエンドポイントについてテストします。テストスイートは下記のテストを含むべきです:

1 . データベースから取得した全ての値が正しいフォーマットで正しくマッピングされたJSONペイロードとして正しく返されることをアサートする大きな「マッピングテスト」。 equals()が正しく実装されているのであれば、AssertJの isEqualTo()（単一の要素用）または containsOnly()（複数の要素用）を使えば簡単にアサートできます。

StringresponseJson=requestProducts();ProductDTOexpectedDTO1=newProductDTO("1","evelope",newCategory("office"),List.of(States.ACTIVE,States.REJECTED));ProductDTOexpectedDTO2=newProductDTO("2","evelope",newCategory("smartphone"),List.of(States.ACTIVE));assertThat(toDTOs(responseJson)).containsOnly(expectedDTO1,expectedDTO2);

2 . クエリパラメータの ?categoryの正しい振る舞いをチェックするテスト。私たちは正しくフィルタリングされるかをテストしたいわけです、全てのプロパティが正しくセットされているかどうかではなく。それは上記のケースで既にテストしています。したがって、返された製品IDだけを比較すれば十分です。

StringresponseJson=requestProductsByCategory("Office");assertThat(toDTOs(responseJson)).extracting(ProductDTO::getId).containsOnly("1","2");

3 . 滅多に起こらないケース、または特別なビジネスロジックをチェックするテスト。たとえば、ペイロードの中の特定の値が正しく計算されているかどうか。このケースだと、興味があるのはペイロードのうち特定のJSONフィールドだけです。そのため、テスト対象のロジックのスコープを明確にして文書化するために、関連するフィールドだけをチェックすべきです。繰り返しますが、全てのフィールドを再度アサートする必要はありません、なぜならここでは関係ないからです。

assertThat(actualProduct.getPrice()).isEqualTo(100);

自己完結したテスト

関連するパラメータを隠さない（ヘルパー関数内）

// 悪い例insertIntoDatabase(createProduct());List<ProductDTO>actualProducts=requestProductsByCategory();assertThat(actualProducts).containsOnly(newProductDTO("1","Office"));

はい、データの生成とアサーションのため、ヘルパー関数を使うべきです。しかし、それらをパラメータ化しなければいけません。テストのために重要で、テストによって制御される必要がある全てに対してパラメータを定義しましょう。ソースを読む人に対して、テスト内容を理解するために関数定義にジャンプさせるようなことを強いてはいけません。経験則: テストメソッドのみを見ることでテストの要点がわかるようにすべきです。

// 良い例insertIntoDatabase(createProduct("1","Office"));List<ProductDTO>actualProducts=requestProductsByCategory("Office");assertThat(actualProducts).containsOnly(newProductDTO("1","Office"));

テストメソッドの中で正しくデータを挿入する

テストメソッドの中では全てが正しくある必要があります。再利用可能なデータの挿入コードを @Beforeメソッドに移動させることは魅惑的ですが、そうするとテストがどうなっているのか完全に理解するためには、ソースを読む人があちこち飛び回らなければならなくなります。繰り返しますが、データを挿入するヘルパー関数はこの繰り返し行うタスクを一行にすることの助けとなります。

継承よりもコンポジションを好む

テストクラスで複雑な継承階層を作ってはいけません。

// 悪い例classSimpleBaseTest{}classAdvancedBaseTestextendsSimpleBaseTest{}classAllInklusiveBaseTestextendsAdvancedBaseTest{}classMyTestextendsAllInklusiveBaseTest{}

このような階層は理解を難しくしますし、あなたは結局現在のテストに必要ないたくさんのものを含むベースのテストクラスを継承することになる可能性が高いです。これはコードを読む人の気を散らし、バグが発生するかもしれません。継承は柔軟ではありません: AllInklusiveBaseTestから継承したものを全てを使うことは不可能ですが、そのスーパークラスの AdvancedBaseTestから継承したものは何もないでしょうか？⁶その上、コードを読む人は全体像を理解するために複数のベースクラスの間を飛び回らなければなりません。

「重複は誤った抽象化よりは良い」
RDX in 10 Modern Software Over-Engineering Mistakes

代わりに、コンポジションを使うことを推奨します。それぞれの特定のフィクスチャの作業ごとに小さいコードスニペットとクラスを書きましょう（テストデータベースの起動、スキーマの生成、データの挿入、モックのウェブサーバの起動）。@BeforeAllを付与したメソッドの中か、もしくは生成されたオブジェクトをテストクラスのフィールドに割り当てることでこれらのパーツを再利用しましょう。それで、あなたはこれらのパーツを再利用することで全ての新しいテストクラスを組み立てます。まるでレゴブロックのように。この方法で、全てのテストは自身にぴったり合った、内容を把握するのが簡単でハプニングとは無縁のフィクスチャを持ちます。そのテストクラスは、全ての関連がテストクラスの中で正しいため、自己完結しています。

// 良い例publicclassMyTest{// 継承の代わりのコンポジションprivateJdbcTemplatetemplate;privateMockWebServertaxService;@BeforeAllpublicvoidsetupDatabaseSchemaAndMockWebServer()throwsIOException{this.template=newDatabaseFixture().startDatabaseAndCreateSchema();this.taxService=newMockWebServer();taxService.start();}}// 別のファイルpublicclassDatabaseFixture{publicJdbcTemplatestartDatabaseAndCreateSchema()throwsIOException{PostgreSQLContainerdb=newPostgreSQLContainer("postgres:11.2-alpine");db.start();DataSourcedataSource=DataSourceBuilder.create().driverClassName("org.postgresql.Driver").username(db.getUsername()).password(db.getPassword()).url(db.getJdbcUrl()).build();JdbcTemplatetemplate=newJdbcTemplate(dataSource);SchemaCreator.createSchema(template);returntemplate;}}

繰り返します:

KISSの原則 > DRY原則

ダンプテストは素晴らしい: 出力とハードコードされた値を比較する

本番コードを再利用しない

テストは本番コードをテストすべきです: 本番コードを再利用するのではなく。もしテストの中で本番コードを再利用すると、もはやそのコードはテストされない⁷ため、再利用されたコードによるバグを見落とすかもしれません。

// 悪い例booleanisActive=true;booleanisRejected=true;insertIntoDatabase(newProduct(1,isActive,isRejected));ProductDTOactualDTO=requestProduct(1);// 本番コードの再利用List<State>expectedStates=ProductionCode.mapBooleansToEnumList(isActive,isRejected);assertThat(actualDTO.states).isEqualTo(expectedStates);

代わりに、テストを書く時、入力と出力という観点から考えましょう。そのテストでは入力値をセットして、実際の出力値とハードコードされた値とを比較します。大抵の場合、コードの再利用は必要ありません。

// 良い例assertThat(actualDTO.states).isEqualTo(List.of(States.ACTIVE,States.REJECTED));

本番コードと同じロジックをテストで書かない

マッピングのコードはテストの中でロジックが再発明される、よくある例です。私たちのテストが、テストの最初に挿入されたエンティティと同じ値を含むことをアサートするのに使われるようなDTO戻り値を返すmapEntityToDto()メソッドを含むとしましょう。この場合、テストコードの中に本番コードと同じロジックを書いてしまう可能性が高いでしょう。それはバグを含むかもしれません。

// 悪い例ProductEntityinputEntity=newProductEntity(1,"evelope","office",false,true,200,10.0);insertIntoDatabase(input);ProductDTOactualDTO=requestProduct(1);// mapEntityToDto() は本番コードと同じマッピングロジックを含むProductDTOexpectedDTO=mapEntityToDto(inputEntity);assertThat(actualDTO).isEqualTo(expectedDTO);

繰り返しますが、解決策は actualDTOと、ハードコードされた値を含む手動で生成した参照オブジェクトを比較することです。それはとてもシンプルで、理解が容易で、エラーが発生しにくいです。

// 良い例ProductDTOexpectedDTO=newProductDTO("1","evelope",newCategory("office"),List.of(States.ACTIVE,States.REJECTED))assertThat(actualDTO).isEqualTo(expectedDTO);

もし全ての値の比較はしたくなくて、それゆえに完全な参照オブジェクトを生成したくなければ、サブオブジェクトのみか、関連する値のみを比較することを検討してください。

ロジックを書きすぎない

繰り返しますが、テストとはほとんど入力と出力に関するものです。入力を提供し、実測値と期待値を比較することです。したがって、テストの中でロジックを書きすぎる必要はないし、そうすべきではありません。もし多数のループと条件を伴うロジックを実装するなら、テストは内容を把握するのが難しく、よりエラーが起こりやすくなります。さらに、複雑なアサーションロジックの場合には、AssertJの強力なアサーションがあなたのために重労働をやってくれます。⁸

現実に近いテスト

完全な垂直スライドのテストに集中する

一般的に、モックを使ってそれぞれのクラスを個別にテストすることが推奨されます。しかし、それには深刻な欠点があります: あなたは全てのクラスを統合してテストしているわけではなく、内部のクラスごとにテストがあるため、内部のリファクタリングが全てのテストを破壊するでしょう。そして最終的に、あなたは様々なテストを書き、メンテナンスしなければなりません。

各クラスを分離してモックを使ってテストすることは欠点をもたらします。

代わりに、統合テストに注目することを提案します。「統合テスト」とは、全てのクラスを一緒にして（本番コードのように）、全ての技術レイヤー（HTTP、ビジネスロジック、データベース）を完璧な垂直スライドで通り抜けるテストのことです。この方法だと、実装ではなく振る舞いをテストします。これらのテストは正確で、本番環境に近く、内部のリファクタリングに対して堅牢です。理想的に、一つのテストを書くだけで済みます。

統合テストに注目することを推奨します(= 現実のオブジェクトを一緒に書き、一度で全てをテストする)

このトピックについては、言うことがもっとたくさんあります。詳細は私のブログ記事の「Focus on Integration Tests Instead of Mock-Based Tests」をチェックしてください。

テストのためにインメモリデータベースを使用しない

インメモリデータベースを使うと、本番環境と違うデータベースに対してテストすることになります

テストのためにインメモリデータベースを使うこと（H2,HSQLDB,Fongo）は信頼性とテストのスコープを減らします。インメモリデータベースと本番環境で使われるデータベースとは異なる振る舞いをし、異なる結果を返すかもしれません。そのため、未熟なインメモリデータベースを基にしたテストは、本番環境のアプリケーションの正しい振る舞いをする保証がありません。その上、あなたは確かな（データベース固有の）機能を使用（またはテスト）することができない状況に簡単にぶつかります。なぜなら、インメモリデータベースはサポートしていないか、もしくは異なる動作をするからです。これについての詳細は、「Don’t use In-Memory Databases for Tests」の記事をチェックしてください。

解決策は実際のデータベースに対するテストを実行することです。幸運にも、Testcontainersというライブラリが、テストコードの中でコンテナを直接管理するための素晴らしいJavaのAPIを提供しています。実行速度を速めるには、ここを見てください。

Java/JVM

-noverify -XX:TieredStopAtLevel=1を使う

常に-noverify -XX:TieredStopAtLevel=1 JVMオプションを実行設定に追加しましょう。それによりテストが実行される前のJVMの起動時間が1〜2秒節約されます。これはIDE経由でテストを頻繁に実行する、テストの初期開発時に特に役に立ちます。

更新: Java 13から、 -noverifyは非推奨です。⁹
Tip: IntelliJ IDEAでは「JUnit」起動設定のテンプレートにこの引数を追加することができるため、新しい実行設定ごとに引数を追加する必要はありません。

AssertJを使う

AssertJは流れるような¹⁰型安全なAPIと、非常にバラエティに富んだアサーション、説明的なエラーメッセージを持った非常に強力で成熟したアサーションライブラリです。
あなたがしたいアサーションの全てがここにあります。これによりテストコードを短く保ちながら、ループや条件を持つ複雑なアサーションロジックを書かずに済みます。いくつかの例を示します:

assertThat(actualProduct).isEqualToIgnoringGivenFields(expectedProduct,"id");assertThat(actualProductList).containsExactly(createProductDTO("1","Smartphone",250.00),createProductDTO("1","Smartphone",250.00));assertThat(actualProductList).usingElementComparatorIgnoringFields("id").containsExactly(expectedProduct1,expectedProduct2);assertThat(actualProductList).extracting(Product::getId).containsExactly("1","2");assertThat(actualProductList).anySatisfy(product->assertThat(product.getDateCreated()).isBetween(instant1,instant2));assertThat(actualProductList).filteredOn(product->product.getCategory().equals("Smartphone")).allSatisfy(product->assertThat(product.isLiked()).isTrue());

assertTrue()と assertFalse()を避ける

単純なassertTrue()や assertFalse()によるアサーションは不可解なエラーメッセージを出力するため避けましょう:

// 悪い例assertTrue(actualProductList.contains(expectedProduct));assertTrue(actualProductList.size()==5);assertTrue(actualProductinstanceofProduct);

expected: <true> but was: <false>

代わりに、特にカスタマイズしなくても¹¹、良いエラーメッセージを出力するAssertJのアサーションを使いましょう。

// 良い例assertThat(actualProductList).contains(expectedProduct);assertThat(actualProductList).hasSize(5);assertThat(actualProduct).isInstanceOf(Product.class);

Expecting:
 <[Product[id=1, name='Samsung Galaxy']]>
to contain:
 <[Product[id=2, name='iPhone']]>
but could not find:
 <[Product[id=2, name='iPhone']]>

もし本当にbooleanに対してチェックしなければならないのであれば、エラーメッセージを改善するためにAssertJのas()の使用を検討してください。

JUnit5を使う

JUnit5は（ユニット）テストのための最先端技術です。活発に開発され、多くの強力な機能(parameterized tests, grouping, conditional tests, lifecycle controlのような)を提供しています。

パラメータ化テストを使う

パラメータ化テストでは一つのテストを異なる値で複数回実行することができます。この方法では、テストコードを追加することなしに複数のケースを簡単にテストすることができます。そういったテストを書くための素晴らしい手段をJUnit5は提供します。@ValueSource、@EnumSource、@CsvSource、そして@MethodSourceです。

// 良い例@ParameterizedTest@ValueSource(strings=["§ed2d","sdf_","123123","§_sdf__dfww!"])publicvoidrejectedInvalidTokens(StringinvalidToken){client.perform(get("/products").param("token",invalidToken)).andExpect(status().is(400))}@ParameterizedTest@EnumSource(WorkflowState::class,mode=EnumSource.Mode.INCLUDE,names=["FAILED","SUCCEEDED"])publicvoiddontProcessWorkflowInCaseOfAFinalState(WorkflowStateitemsInitialState){// ...}

私はこれらを広範囲に使うことを強く推奨します。なぜなら、最小限の努力でより多くのケースをテストできるからです。

最後に、パラメータで期待値もコントロールできる、より発展的なパラメータ化テストシナリオのために使用できる@CsvSourceと@MethodSourceのことを強調したいと思います。

@ParameterizedTest@CsvSource({"1, 1, 2","5, 3, 8","10, -20, -10"})publicvoidadd(intsummand1,intsummand2,intexpectedSum){assertThat(calculator.add(summand1,summand2)).isEqualTo(expectedSum);}

@MethodSourceは、全ての関連するテストパラメータと期待値を含む専用のテストオブジェクトと組み合わせて使うと強力です。残念ながら、Javaでは、これらのデータ構造（POJO）を書くことが面倒です。それが、下記でこの機能の例を示すのにKotlinのデータクラスを使う理由です。

data classTestData(valinput:String?,valexpected:Token?)@ParameterizedTest@MethodSource("validTokenProvider")fun`parsevalidtokens`(data:TestData){assertThat(parse(data.input)).isEqualTo(data.expected)}privatefunvalidTokenProvider()=Stream.of(TestData(input="1511443755_2",expected=Token(1511443755,"2")),TestData(input="151175_13521",expected=Token(151175,"13521")),TestData(input="151144375_id",expected=Token(151144375,"id")),TestData(input="15114437599_1",expected=Token(15114437599,"1")),TestData(input=null,expected=null))