HTML5 (今は HTML Living Standard) が登場した時、これで「アプリ」やゲームを開発できる、と宣伝されました。筆者も嘗ては HTML5 に夢を見ました。
今は HTML5 をそこまで良いと感じません。
元々、この記事は上記リストに反論する形式でしたが、書き方を改めました。
確かに「HTML5 アプリ」は簡単に作れますが、開発者の多くは HTML5 に「フレームワーク」や NodeJS (npm) を採用して、構造を複雑にします。また、HTML5 を普通のソフトに見せかけるために「Electron」でラップすると、実行可能ファイルは巨大になり、消費メモリーも増加します。
HTML5 は、自分のウェブサーバーから「アプリ」を配信できる、と注目されましたが、多くの場合は、ネイティブの WebView に埋め込まれ、Google や Apple の「ストア」で配布されます。WebView を使用しなくても、モバイルのブラウザーの殆どは Chrome・Safari の派生だから、結局は Google や Apple から逃げられません。
HTML5 のゲームはプログラミングの学習に丁度良く、家族や友人に成果物を見せて楽しむ事ができます。ところが本格的なゲーム開発には向かず、ネイティブのゲームには見劣りします。筆者の経験上、多くの人はブラウザゲームより、ハイエンドゲームや市販ゲームを好みます。
開発上の課題もあります。いくら効率の良いコードを書いても、ブラウザー側の制約により、ゲームのアニメーションは不安定になります。更に、JS でキーボードやマウスの情報を取得する API は複雑で、PC・モバイルの両方に対応するには沢山のコードが必要です。
HTML5 の canvas はフィンガープリントに使用できます。それどころか JS にはプライバシー侵害のための機能があります (HTML5 と少し別の話ですが、参考として)。
このメソッドは、アナリティクスや診断のために、データの送信が早すぎるとデータ収集の機会を失う可能性があるような場合、文書がアンロードされる前にサーバーにデータを送信するものです。例えば、他のページに移動してページがアンロードされる前にユーザーがどのリンクをクリックしたかなどです。
HTML5 以降「アプリ」のための機能が増えましたが、ハイパーテキストを記述する機能は殆ど進歩しません。header などの新要素は DIV の親戚に過ぎず、しかも互換性の問題を増やしました。むしろ、同時期にできた CSS3 の方が便利かもしれません。CSS3 は、ウェブサイトの表現の幅を大きく広げました。
このサイトは HTML i18n で書きました。1997年の規格ですが機能は充分です。HTML5 や HTML Living Standard で HTML の規格を何度も更新するのは蛇足といつても過言でありません。
1つ目の理由は、それらはブラウザを非常に複雑なプラットフォームにしてしまうからだ。そして、複雑さは敵（攻撃者）の武器だ。私たちは実際にシンプルで、標準的で、一般的なものとしてプラットフォームを見るべき。HTML5はそうしなかった。
iOS10から、Safariで viewport の user-scalable=no が効かなくなりました。
ブラウザゲームなどを開発してる場合、ダブルタップで拡大されてしまうためクリティカルな問題になります。