この記事は Malte Ubl による The AMP Blog の記事 "AMP is joining the OpenJS Foundation incubation program" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

AMP Project を代表して、AMP が OpenJS Foundation インキュベーション プログラムに合流することをお知らせします。

AMP は、ウェブ デベロッパーが高速でユーザー フレンドリーな体験を簡単に作成できるフレームワークを提供することを目指し、4 年前にオープンソース プロジェクトとして誕生しました。私たちは、AMP を貢献者にとって心地よいコミュニティにすることを目指し、これまで約 1000 人の貢献者が AMP にコードを提供してくれました。

昨年はコミュニティと連携してガバナンス モデルの改善に取り組みました。技術面、プロダクト面での AMP の方向性にコミュニティの多様な声を反映し、多くの AMP ステークホルダーや支持者の意見を代弁したものにするためです。

ガバナンスの変更に合わせて、今後の方針として、コミュニティが新しいガバナンス モデルに適応し、AMP にふさわしい財団が見つかった際には、AMP をその財団に移管することを発表しました。そして今、そのときがやってきました。さまざまな選択肢の中から AMP のすべてのニーズを満たす財団を検討してきましたが、AMP の理想的なホームとして OpenJS Foundation が際立っていることがわかりました。

OpenJS Foundation が AMP に ふさわしい理由はいろいろありますが、代表的なものを以下に示します。

• 「ユーザー ファーストなウェブ コンテンツのフォーマット」を提供するという AMP のミッションは、「主要な JavaScript およびウェブのソリューション、その関連技術の普及と継続的な開発を推進する」という Open JS Foundation の目的とぴったり一致しています。
• OpenJS Foundation では、プロジェクト自体や技術的な指向、プロダクトの方向性に関する独自性が保たれています。一方で、資金調達の仕組みや法的なサポートなど、プロジェクトが財団に求める重要な支援サービスが提供されています。
• AMP の新しいガバナンス モデルは、Open JS Foundation の母体となった JS Foundation と Node.js Foundation という 2 つの組織のガバナンス モデルから大きな影響を受けているので、AMP と Open JS Foundation のガバナンス理念にはもとより整合性があります。

財団を探す過程や OpenJS Foundation を選択した理由の詳細については、本日、AMP アドバイザリー コミッティ メンバーの Tobie Langel 氏および OpenJS Foundation のエグゼクティブ ディレクターである Robin Ginn 氏が AMP Contributor Summit で行うプレゼンテーションをご覧ください。

先日には、AMP のテクニカル ステアリング コミッティとアドバイザリー コミッティの承認のもと、AMP は OpenJS Foundation のプロジェクト提案プロセスを開始しました。そして、OpenJS Foundation の Cross Project Council（CPC）は、提案のレビューを経て、AMP を財団のインキュベーション プログラムとして受け入れました。今後数か月間のうちに、AMP は OpenJS Foundation と連携してオンボーディング チェックリストを完了させ、財団に合流する予定です。

Google は今後も AMP を強力にサポートします。Google は既に OpenJS Foundation のプラチナ メンバーになっています。AMP のコミュニティやエコシステムの繁栄を確かなものにするため、これからも金銭面を含めたサポートを続けます。AMP オープンソース プロジェクトの専任として貢献している Google 社員のチームも継続します。

インキュベーション フェーズ以降、さまざまな OpenJS Foundation コミュニティと連携し、オープンで持続可能なウェブを維持できることを楽しみにしています。

Malte Ubl（AMP テクニカル ステアリング コミッティを代表して）



Reviewed by Chiko Shimizu - Developer Relations Team

この記事は Naina Raisinghani による The AMP Blog の記事 "amp-script: AMP ❤️ JS" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

今年の AMP Conf では、<amp-script> のデベロッパー プレビューを紹介しました。本日は、<amp-script> の一般公開についてお知らせします。カスタム JavaScript は、AMP コンポーネントによって別の Worker スレッドで実行されます。そのため、超高速な AMP ページはそのままに、カスタム JavaScript を追加できるようになります。
<amp-script> を使うと、既存の AMP コンポーネントでは実現できなかったユースケースに対応できます。また、AMP ページと非 AMP ページでコードを共有することもできます。JavaScript フレームワークを使うことも可能です。次にあげるのは、<amp-script> チームが構築してきたいくつかのサンプルです。

• Vue を使った Todo MVC
• パスワード チェッカー
• D3.js を使ったニュース記事のデータ視覚化
• 次のセクションに移動する前に検証が必要になる複数ページフォーム（下のイメージ）

上の例を見て興味を持った方は、<amp-script> を試してみてください。なお、AMP のパフォーマンスを保証するために、いくつか制約がある点に注意が必要です。

• コンテンツのジャンプ: 通常の <amp-script> では、意図しないコンテンツのジャンプを回避するため、ユーザーのジェスチャーが発生しないとページのコンテンツを変更することはできません。 
• ページ読み込み: <amp-script> はユーザーの操作なしにページのコンテンツを変更することはできないので、ページの読み込み時にコンテンツを変更することもできません。
• スクリプトのサイズ: 1 つの <amp-script> で使うスクリプトは、150 kB 以下である必要があります。なお、お気に入りの JS フレームワークを使うことはできますが、150 K の制限内に収まっている必要があります。
• API のサポート: Web Worker ですべての API がサポートされているとは限りません。WorkerDOM には、許可されている API のリストが掲載されています。また、いくつかの DOM のメソッドやプロパティはまだ実装されていません。リスト全体は、WorkerDOM の互換性で公開されています。追加してほしい API がある方は、問題として送信してください、

<amp-script> は、React、Preact、Angular、Vue.js、jQuery、D3.js など、皆さんが既に利用しているかもしれないフレームワークに対応しています。

この点は、AMP を使っているデベロッパーから寄せられた最も重要な要望でした。AMP Project は、スピードという AMP の価値提案を維持しつつ、この要望に対処できたことをうれしく思っています。<amp-script> の動作の詳細については、こちらをご覧ください。また、このガイドに従って <amp-script> を試してみてください。このすばらしい手法を使うと、これまでは不可能だったたくさんのユースケースを実現できるようになります。

<amp-script> の使用に関する問題や機能リクエストがありましたら、遠慮なくお知らせください。


投稿者: Naina Raisinghani（Google AMP Project、プロダクト マネージャー）


Reviewed by Chiko Shimizu - Developer Relations Team

この記事はデベロッパー アドボケート、Doug Stevenson による The Firebase Blog の記事 "Keep your promises when using Cloud Functions for Firebase!" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 　
　
多くの Firebase デベロッパーは、Android、iOS、ウェブのいずれか、または 3 つすべてのアプリの開発に集中しています。私のように、ほとんどの時間をクライアント側の開発にかけている場合、バックエンド側のコンポーネント開発は難しいと感じるかもしれません。しかし Cloud Functions for Firebase を活用することで、サーバー管理を気にせずに、簡単に楽しく JavaScript でバックエンド側のコードを書いたり、デプロイしたりすることができます。私の場合は Android プログラミングが得意分野ですので、Cloud Functions をマスターするために、JavaScript の理解をブラッシュアップし、node.js を学習しました。 　

Promise の紹介

JavaScript と node.js について学習する中で、Promise という非同期タスクの管理方法を学びました。ブラウザで JavaScript や Cloud Functions を使ったことがある方はすでにご存知かもしれませんが、Promise は、非同期タスクを処理するに良く使われるクラスです。Android の Firebase API にたまに出てくる Task API に近いコンセプトです。 　
　
Promise は、データベースへの書き込み、ネットワーク リクエストなどの非同期タスクを実装するときに利用します。非同期タスクの実行中に関数を終了させないようにするには、関数から Promise を返します（ただし、クライアントに応答を送信する必要がある HTTP/S トリガーは除きます）。Promise を返すときは、その関数のすべての 非同期タスクが完了した際に Resolve される Promise を返すようにします。YouTube の Firebase チャンネルにある以下の動画では、Cloud Functions での Promise の動作を紹介しています。 　
　

以上の動画には、Jen が Promise の 2 つの使い方を紹介します。1 つ目は複数のタスクを連結して順番に処理するために使われる Promise の then() メソッドです。2 つ目は複数のタスクを並列に実行し、すべての タスクが完了するまで待機する Promise.all() メソットです。この 2 つのメカニズムを活用すると、関数内に行われるほとんどの処理を実装することができます。タスクが完了したときに、Promise を返して、Cloud Functions 環境にクリーンアップ処理を任せます。 　
　

ECONNRESET 問題

シンプルな処理は作りやすいのですが、多数の Promise が同時に実行される複雑なタスクはなかなか実装しにくいケースがあります。Promise が正しく実装されていないときのひとつの症状として、Firebase console のログに次のようなエラーが表示される場合があります。 　
Error: read ECONNRESET 　
このエラーに関しては、いくつかの原因が考えられます。クライアント ライブラリのバグである可能性もありますが、ほとんどの場合は、Promise が正しく使われていないことが原因です。 　
ネットワーク接続が完了する前に関数が終了すると、オープンされているコネクションは強制的にクローズされることがあります。この場合ログに ECONNRESET が記録されます。これは、次のような状況で発生します： 　
例えば、3 つの非同期タスクを起動する必要があるプログラムを考えましょう。次のように、Promise を返す doSomeAsync() で、3 つのタスクを起動して、3 つ目のタスクの Promise を返します。 　

doSomeAsync(x)
doSomeAsync(y)
return doSomeAsync(z)

関数から Promise を返すこと自体には問題がありません。しかし、Cloud Functions では、すべての タスクが完了するまで待機する Promise が必要です。上の書き方だと、1 つ目のタスクと 2 つ目のタスクが 3 つ目のタスクが完了する前に完了する保証がありません。3 つ目のタスクが 1 つ目のタスクや 2 つ目のタスクより前に完了すると、Cloud Functions は実行中のタスクをクリーンアップしてしまう可能性があります。 　
このプログラムを修正するには、すべての Promise を組み合わせた新しい Promise を作る必要があります。この Promise は、すべての Promise が完了するまで待機して Resolve します。正しい書き方は以下のとおりです。 　

const promise_x = doSomeAsync(x)
const promise_y = doSomeAsync(y)
const promise_z = doSomeAsync(z)
return Promise.all([promise_x, promise_y, promise_z])

関数内で起動した すべての非同期タスクをきちんと管理しないと、ログに恐怖の ECONNRESET エラーが出現し、プログラムは予想通りに動作しない可能性があります。すべての Promise をきちんと管理するには、人がすべての約束を守るのと同じように、ある種の努力が必要です。 　
Google I/O '17 のセッションで、私が作ったオープンソースのウェブ 3 目並べゲームを紹介しました。このゲームは完全に Firebase だけで作成し、複雑な非同期タスクを実装しています。こちらの動画を御覧ください。 　

Cloud Functions に関するその他のチュートリアルやコンテンツ、他の Firebase 製品にご興味がある方は、YouTube の Firebase チャンネルや Firebase ブログをご覧ください。 　
　
Reviewed by Oscar Rodríguez - Developer Relations Team

この記事は「型破りなモジュール使い」、Domenic Denicola による Chromium Blog の記事 "Chrome 61 Beta: JavaScript modules, Payment Request API on desktop, Web Share API, and WebUSB " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 　
特に記載のない限り、下記の変更は Android、Chrome OS、Linux、Mac、Windows 向けの最新の Chrome ベータ版に適用されます。 　

JavaScript モジュール 　

モジュールを使うと、スクリプトの依存性を宣言できます。サードパーティ製ビルドツールでは、必須スクリプトのみをバンドルするためにモジュールを使用するのがすでに一般的です。 今回のリリースでは、JavaScript モジュールが新しい <script type=module> 要素でネイティブ サポートされます。 ネイティブ サポートとは、ビルドのステップを経ずに、ブラウザが細かい単位で依存性を並列に取得し、キャッシュを活用してページ間の重複を防ぎ、正しい順序でのスクリプトの実行が保証されることを意味します。 　
導入にあたっては、JavaScript モジュールの詳細や、モジュールの影響を受ける JavaScript 言語の機能について確認してください。 　

デスクトップ版 Payment Request API 　

昨年サポートが発表された Android 版に続き、Windows、Mac、Linux、ChromeOS でも Payment Request API が利用できるようになります。デベロッパーは、プラットフォームを問わず安全でシームレスな購入手続きを提供できます。導入にあたっては、統合ガイドをご確認ください。 　

Web Share API 　

ユーザーがソーシャル ネットワークで簡単にコンテンツを共有できるようにするには、各ソーシャル サービス用の共有ボタンを手動でサイトに組み込む必要があります。そのため、ユーザーが実際に使っているサービスで共有できないことも多く、ページサイズの肥大化やサードパーティ製コードを含めることによるセキュリティ リスクも発生しています。 　
Chrome for Android では、新しく navigator.share API が利用できるようになっています。これは、Android ネイティブの共有ダイアログを呼び出すことにより、インストールされている任意のネイティブ アプリで簡単にテキストやリンクを共有できるようにするものです。今後のリリースでは、インストールされているウェブアプリとの共有もできるようになる予定です。 　

WebUSB 　

高レベルのウェブ プラットフォーム API は、キーボード、マウス、プリンター、ゲームパッドなど、ほとんどのハードウェア機器をサポートしています。しかし、特殊な教育、科学、産業用の USB 機器を使う場合は、安全ではない可能性があるドライバやソフトウェアを検索してシステムレベルの権限を使ってインストールする必要があります。 　
今回、Chrome で WebUSB API がサポートされました。これにより、ユーザーの同意を得た上で、ウェブアプリが機器と通信できるようになります。各デバイスが提供するすべての機能を利用できますが、ウェブのセキュリティが保証される点は変わりません。 　

今回のリリースに追加されたその他の機能 　

• Android に加えて、PC でも Network Information API が利用できるようになりました。これを使うと、サイトから基盤となる端末の接続情報にアクセスできます。 
• 既存の Scroll API の新しいオプション パラメータ、または scroll-behavior CSS プロパティを使って、スムーズなスクロールを指定できるようになりました。 
• プラットフォームで、CSSOM View Smooth Scroll API を使ってスムーズなネイティブ スクロールを実現できます。これには、scroll-behavior: smooth CSS プロパティまたは window.scrollTo() DOM スクロール メソッドを利用します。JavaScript でこの動作を実装する必要はなくなります。 
• CSS の色の値は、8 桁および 4 桁 の 16 進数を使って #RRGGBBAA および #RGBA という形式で指定するようになります。 
• Visual Viewport API によって、サイトから相対位置で画面の内容にアクセスできるようになりました。これを使うと、ピンチしてズームなどの複雑な機能を直接的な方法で実現できます。 
• Device RAM API を利用できるようになりました。サイトからユーザーの端末の RAM の量を参照できるようになるため、ウェブ アプリケーションの全体的なパフォーマンスを最適化できます。 
• インストールされたウェブアプリを操作して最初のウェブアプリのスコープ外のサイトに移動する場合、新しいサイトが自動的にカスタム Chrome タブで読み込まれるようになりました。 
• ネイティブ コントロールを利用している動画の再生中に、ユーザーが動画と一致する向きに端末を回転すると、Chrome が自動的に動画を全画面に拡大するようになりました。 
• nextHopProtocol が Resource Timing および Navigation Timing で利用できるようになりました。これにより、リソースの取得に利用するネットワーク プロトコルにアクセスできるようになります。 
• サイトでサードパーティ製埋め込みコンテンツにコンテンツ セキュリティ ポリシーを強制できるようになりました。これには、<iframe> 要素に新しく追加された csp 属性を使用します。 
• DOMTokenList インターフェースで replace() がサポートされました。これにより、すべての同じトークンを簡単に新しいものに変更できます。たとえば、有効期限が切れた際に、active を inactive に変更できます。 
• 要素の attribute 名のリストにアクセスする getAttributeNames() がサポートされました。これにより、attributes コレクションに対して反復処理を行うよりも直接的な仕組みが提供されます。 
• セキュリティ強化のため、JavaScript ダイアログが開いた際に自動的に全画面を終了するようになります。 
• サイトから、指定されたオリジンや quota で使用されるディスク スペースの大まかなバイト数にアクセスできるようになりました。これには、Storage API に新しく追加された navigator.storage.estimate() 関数を使用します。 
• ブラウザのキャッシュ ヒット率を上げるために、URLSearchParams で sort() がサポートされました。これは、格納されているすべての名前と値のペアを並び替えて出力します。 
• URLSearchParams のコンストラクタが更新され、他の URLSearchParams インスタンスだけではなく、任意のオブジェクトをパラメータとして渡せるようになりました。 
• 誤って発行された証明書を気づかずに使ってしまうことがないように、サイトで新しい Expect-CT HTTP ヘッダー が使われるようになりました。これによって、レポートの自動化や Certificate Transparency 要件の強制が可能になります。 
• Chrome のバックグラウンド タブで、Media Source による動画フレームのデコードが行われなくなりました。 
• ImageCapture.getPhotoSettings() で、写真の解像度、赤目軽減、フラッシュ モードなどの「ライブでない」カメラ設定を取得できるようになります。
• サイトは Clear-Site-Data ヘッダーを使って cookie や service worker、キャッシュエントリなどのクライアントサイドデータを削除できるようになります。

サポートの終了と相互運用性の改善 　

• セキュリティ強化のため、URL に \n と < の両方の文字が含まれるリソースはブロックされるようになります。 
• セキュリティ強化のため、安全でないコンテキストで Presentation API の start 関数がサポートされなくなり、削除されました。 
• on<event> 属性間の一貫性を向上させるため、onwheel 属性が Element から Window、Document、HTMLElement、SVGElement に移動します。 
• 仕様に準拠し、さらに細かい参照コンテンツのフロー制御を実現するため、Chrome で 3 つの新しい Referrer Policy 値である same-origin、strict-origin、strict-origin-when-cross-origin がサポートされました。 
• 仕様の変更に従い、colSpan の最大値が 8190 から 1000 に下がりました。

　
Reviewed by Eiji Kitamura - Developer Relations Team

[この記事は Jacob Wenger、ソフトウェア エンジニアによる Firebase Blog の記事 "Firebase and React Native" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

継続的にフィードバックをお寄せいただいているおかげで、JavaScript SDK のバージョン 3.1.0 で Firebase の React Native サポートが強化されました。それだけではありません。このバージョンでは、Node.js SDK からの認証されていないアクセスも追加されているため、サービス アカウントなしにアプリを初期化できるようになっています。これにはどのような意味があるのでしょうか。詳しく見ていきましょう。

React Native のサポート

Google I/O で Firebase 3.x SDK がリリースされた際、SDK の認証部分は React Native と互換性がなくなっていました。リリース 3.1.0 では、ブラウザ固有の API を置き換えることによって、再び Firebase に React Native との互換性を持たせています。さらに、アプリの再起動をまたぐ認証状態の永続化など、React Native で Firebase を使用する際に問題となってきた点が修正されています。これによって、その他の JavaScript アプリと同様、Firebase プロジェクトを初期化するだけでよくなります。

import ReactNative from "react-native";
import firebase from "firebase";
// Initialize Firebase
const firebaseConfig = {
  apiKey: "<YOUR-API-KEY>",
  authDomain: "<YOUR-AUTH-DOMAIN>",
  databaseURL: "<YOUR-DATABASE-URL>",
  storageBucket: "<YOUR-STORAGE-BUCKET>"
};
firebase.initializeApp(firebaseConfig);

3.1.0 SDK のアップデートでは、React Native でほぼすべての JavaScript SDK の機能がスムーズに動作するようになっています。ただし、いくつかの注意点があります。

• signInWithPopup()、signInWithRedirect()、linkWithPopup()、linkWithRedirect() などの「ヘッドフル」な認証メソッドは、React Native では動作しません（この点は Cordova でも同様です）。ただし、signInWithCredential() と任意のプロバイダからの OAuth トークンを利用することで、フェデレーションに対応したプロバイダにログインしたり、リンクすることができます。
• React Native は File や Blob タイプをサポートしていないので、この環境では Firebase Storage へのアップロードは動作しません。ファイルのダウンロードは問題なく動作します。

未認証アクセス

リリース 3.1.0 のもう 1 つの特徴は、Node.js SDK で未認証アクセスがサポートされていることです。以前は、Node.js SDK を利用するにはサービス アカウントが必須でした。そのため、Firebase Console でのサービス アカウント キーの作成、サーバーへのダウンロード、コードからファイルを参照して認証、という作業を行う必要がありました。トークンの作成や検証には依然としてサービス アカウントが必要ですが、Node.js のユースケースによっては、サービス アカウントを使わないで済むこともあります。最新の SDK では、この要件を緩和してデータベース URL だけでアプリを初期化できるようにしています。

import firebase from "firebase";
firebase.initializeApp({
  databaseURL: "<YOUR-DATABASE-URL>",
});

サービス アカウントがない場合、他の未認証クライアントと同様に Realtime Database へのアクセスは制限されます。

フィードバックをお待ちしています

Slack のチームや Google Group、その他のサポート窓口より意見をお寄せいただき、ありがとうございました。新しい SDK で何か問題が発生した場合は、こちらからご連絡ください。React Native や Firebase に関して皆さまからのご意見をお待ちしています。


Posted by Yoshifumi Yamaguchi - Developer Relations Team

[この記事は Seth Thompson、プロダクト マネージャーおよび ECMAScript ESsayist（ES エッセイスト）による Chromium Blog の記事 "ES6 & ES7 in the browser" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

JavaScript は進化し続けるプログラミング言語で、ブラウザ ベンダー、デベロッパー、コミュニティ メンバーからなる委員会によって時間をかけて標準化されています。ここ 2 年間で、この委員会は JavaScript 史上最大のアップデートとなる ES6 と、更新頻度が年次になって初めてのアップデートとなる ES7 を発表しました。この 2 つのバージョンには合計で何百もの新機能が追加されており、デベロッパーは豊かな表現力を持つ簡潔で高速なアプリケーションを書けるようになります。V8 JavaScript チームは長い間、設計、仕様の策定、実装という作業に協力して取り組んできました。その結果、言語サポートの大きなマイルストーンとなる地点に到達しました。今日現在の Chrome Canary では、ES6 と ES7 の両方が動作するようになっています。これは、Chrome 52 ですべてのユーザーに提供される予定です。

Chromium での ES6 と ES7 のサポートによって、JavaScript デベロッパーが長らく求めていた機能が提供されます。他のプログラミング言語には標準であっても、ウェブの世界には存在しなかったもので、具体的には、一般的なプログラミング パターンを簡略化する方法、コードを書きやすくする方法、JavaScript の動作を低レベルでカスタマイズする方法などです。たとえば、クラスによってオブジェクト指向プログラムの記述が簡単になり、JavaScript のビルトイン オブジェクトを安全に拡張できるようにもなります。アロー関数、デフォルト パラメータ、配列関連のユーティリティ メソッドによって慣用的なプログラムが簡単に書けるようになり、プロジェクト間でボイラープレート コードのコピー & ペーストを行う必要性が少なくなります。JavaScript の非同期実行フローやネストされたコールバックを読み解くのは非常に難しいことがあります。そのため、ES6 で Promise や、イテレータとジェネレータが導入されました。これによって非同期コードがシンプルになり、制御フローの表現力が向上して、バグのないコードを簡単に書けるようになっています。高度なデベロッパーは、Proxy やよく使うシンボルのような強力な機能を活用して、言語の動作がアプリケーションのニーズに適したものになるようにカスタマイズすることもできます。

ウェブサイトでこのような JavaScript の新機能をフル活用するには、複数のブラウザが最新仕様をサポートする必要があります。幸いにも、クロスブラウザのサポートはここ数か月間で急速に改善されています。すべてのモダン ブラウザの最新の開発バージョンでは、ES6 の 90% 以上がサポートされています。Polyfill やトランスパイルによって古いブラウザをサポートすることもできます。最近、<script type="module"> タグによって HTML からの JavaScript モジュールの読み込みが標準化されたことを考えると、今後、採用は拡大し続けることでしょう。Chromium は既にこの新しいタグの実装に着手しており、モジュールのサポートは近日中に提供する予定です。これによって、ES6 や ES7 のコードでウェブサイトを記述し、稼働させることがさらに簡単になります。

JavaScript 標準プロセスについてや、適切な tail call などの検討中の新機能、仕様の適合性についての技術的な詳細を知りたい方は、V8 ブログをご覧ください。最新の JavaScript 機能や継続的に行われているパフォーマンスの最適化についても報告しますので、このページも随時ご確認ください。


Posted by Eiji Kitamura - Developer Relations Team

[この記事は Sarah Clark、Google デベロッパー トレーニング プログラム マネージャーによる Android Developers Blog の記事 "Get ready for Javascript “Promises” with Google and Udacity" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

フロントエンド ウェブ デベロッパーは、一般的な「非同期」リクエストを使う際、いくつもの困難に直面します。URL の取得やファイルの読み込みといったこれらの非同期リクエストは、とくに複数のアクションを連続して行う場合に複雑なコードになりがちです。デベロッパーが非同期リクエストをもっと簡単に使えるようにするには、どうすればよいでしょうか。

JavaScript Promises は非同期コードを簡略化する新しいツールで、コールバックやイベント ハンドラーが絡み合ったコードを次のようにシンプルで分かりやすくします。

fetch(url).then(decodeJSON).then(addToPage)...

Promise は Service Worker、Fetch API、Quota Management、 Font Load Events、Web MIDI、Streams など、多くの新しいウェブ標準として使用されています。


Google は Udacity と共同で Promises のオンライン コースを開発し、公開しました。これは、約 1 日で完結する短時間のコースで、Promises を使ってライブデータの読み込みと表示を行う「Exoplanet Explorer」アプリの構築が体験できます。Fetch API の使い方も学べるので、このコースを終えれば、XMLHttpRequest とはお別れです。

この短期コースはシニア ウェブ デベロッパー Nanodegree コースの 必須科目でもあります。Nanodegree コースの受講は有料ですが、本コースを単体で受講する場合は無料です。どちらかのコースを受講して、コードをよりシンプルに、信頼性を高くする方法を本日から学びませんか。

無料コースのお申し込みはこちらから。

※ 無料コースのご受講は、Udacity の受講を推進する Study Jams プログラムの一貫となります。上記の Study Jams 申し込みフォームに必要事項をご記入いただき、参加コースを「[上級] JavaScript Promises (ud898) 」としてご登録ください。その後、Udacity コース申し込みリンクをお送りします。　

Posted by Takuo Suzuki - Developer Relations Team

[この記事は Ben L. Titzer、ソフトウェア エンジニア、TurboFan メカニックによる Chromium Blog の記事 "Revving up JavaScript performance with TurboFan" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

JavaScript のエコシステムはいくつかの方法で進化しています。たとえば、最近承認された ECMAScript 2015 や実験初期段階の Strong Mode など、主な標準がさらに高度な仕様に更新されています。こうした新しい方向性のニーズとのバランスを取るには、柔軟な実行時（JIT）コンパイラーが必要であり、私たちは「TurboFan」というコード名の V8 向け最新コンパイラーに重点的に取り組んできました。Chrome 41 以降、特定のタイプのコードで TurboFan が有効になっています。これは、従来のコンテンツを高速化するとともに、新しい言語機能のパフォーマンスを改善します。

TurboFan は固有の機能を多く搭載することを念頭に、新しく構築されました。以前の最適化コンパイラーよりも多くのコードを最適化し、フレキシブルで変化の多い最適化モードをサポートしており、コントリビューションやメンテナンスがより簡単になります。これらの機能によって、以前のコンパイラーで最適化を行うには困難であった、scope、computed property 名、for-of ループを使用した asm.js や class リテラルなどの一部のコードタイプにおいても TurboFan を使用できるようになりました。TurboFan はすでに、Octane ベンチマークの zlib スコアが 29% 上昇するなど、今後が期待できるパフォーマンスを発揮しています。

私たちは今後数か月で、TurboFan をより多くの JavaScript で使用できるようにし、最終的には既存の CrankShaft コンパイラーから完全に移行することを目標としています。TurboFan が展開されると、デベロッパーのコードが自動的に高速化されます。コストはかからず、変更の必要もありません。今後の進捗にご期待ください。

Posted by Eiji Kitamura - Developer Relations Team

[この記事は Marja Hölttä、Daniel Vogelheim による Chromium Blog の記事 "New JavaScript techniques for rapid page loads" を元に、北村が翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Chrome の主な使命の 1 つは、2008 年に基本原則の 1 つとして明言されて以来、ずっとスピードです。しかし現在、スピードは単に Javascript ベンチマークの結果というだけではなくなりました。ブラウザを使ったすべてのユーザー操作において、ウェブページの表示や読み込みがすみやかに行われることが理想的です。Chrome では、スクリプト ストリーミングとコード キャッシングという 2 つの技術を採用し、特にモバイル端末において白い画面が表示される、イライラする待ち時間を低減しています。

スクリプト ストリーミングは JavaScript ファイルのパースを最適化します。以前のバージョンの Chrome では、パースを開始する前にスクリプトをすべてダウンロードする単純な手法を使っていましたが、このアプローチではダウンロードが終了するまで CPU を活用できていませんでした。Chrome バージョン 41 からは、async と deferred のスクリプトについて、ダウンロードが開始されると同時に別のスレッドでパースが実行されるようになります。つまり、ダウンロードの完了とほぼ同時にパースも完了することになり、ページの読み込みが 10 % ほど迅速に行われることになります。これは特に大がかりなスクリプトやネットワークが遅い状況において効果的です。



コード キャッシングはもうひとつの新たな技術で、特に同じページを何度も表示するときにページが迅速に読み込まれるようになります。通常、ページの JavaScript はページを表示するたびに V8 エンジンによってコンパイルされ、プロセッサが認識できるインストラクションに変換されますが、このコンパイル済みのコードは、コンパイル実行時のマシンの状況やコンテキストによって大きく左右されるため、ユーザーがそのページから移動すると保持されません。Chrome 42 では、このコンパイル済みコードのローカルコピーを保持する拡張技術を採用することで、ユーザーがそのページに戻ってきたときにダウンロード、パース、コンパイルの手順をすべて省略できるようになります。これによってすべてのページでコンパイル時間の 40% を削減し、モバイル端末において貴重なバッテリーの消費量を減らすことができます。

以上が Chrome によってページの読み込み時間を抑える 2 つの技術についての説明になりますが、ページの読み込み時間はブラウザのパフォーマンスを向上する 1 つの手段にすぎません。Chromium プロジェクトで進められるウェブ パフォーマンスのすべての側面における改善を、今後もご期待ください。

Posted by Eiji Kitamura - Developer Relations Team