Hello.

Jeff PosnickがWorkboxに書き込みます

A common source of unexpectedly high quota usage is due to runtime caching of opaque responses, which is to say, cross-origin responses to requests made without CORS enabled.

Browsers automatically inflate the quota impact of those opaque responses as a security consideration. In Chrome, for instance, even an opaque response of a few kilobytes will end up contributing around 7 megabytes towards your quota usage.

全文を読む

サービスワーカーは、Webエコシステムの驚くべきで不可欠な部分ですが、まだかなりの問題があります。これは、事前にこれを知っていなければ、あなたを噛む可能性があります。

Workboxのようなツールを見て、これを処理して何が起こるかを知ることができるようになることは素晴らしいことです。

Dev.toのSam Thorogoodは次のように書いています。

Why did I write this post? Emscripten is a wonderful tool, but it has a long history (for asm.js), and isn’t perfect. I think it errs too much on the side of “magic”, and many posts rave about how it’s so easy to EMASM or use binding-fu, but this all comes at a cost, and can introduce huge amounts of inadvertent overhead—think copying huge memory buffers around because we’re trying to make them immutable or easily exposed.

Every language that is being compiled to Web Assembly needs a runtime—whether it be Go, or Rust, or C/C++ as we have here. I don’t believe that we’ll ever really be able to directly import Web Assembly via ES2015 modules, at least not without changes on the JS side. But it behooves us to write the smallest one we possibly can.

全文を読む。

私たちは誰もがうまくいくと思っています。私たちの多くは、今やウェブに来ることができる他の多くのプラットフォームが、私たちにとって全く異質なものです。これらのツールを学び、wasm開発者の経験を向上させる必要がありますそして、「伝統的なWeb開発者」がちょうど使うことができる事前ビルドされたライブラリを提供しています。

Google ChromeのMustafa、Dev-Channelの書き込み、

The Gestalt principles are a series of laws that are used to explain why human beings naturally find organized patterns in objects they see around them. The goal with the principles was to explain why we group objects in some ways but not others.

There are many different principles, but here I am going to look at the ones that effect grouping, these are; proximity, similarity, common fate, continuity, closure, and prägnanz.

全文を読む。

Share Target API is now in Chrome breaking down one of the last silos of native platforms

Use onappinstalled to detect when a progressive web app is installed.

A simple bookmarklet that will performance trace the current page and open in an hosted devtools instance

A simple docker container that can host an instance of puppeteer and a custom app.

A curl-like utitly that runs JavaScript

CSP nonce values can help you securely run inline content on you site. But it can be hard to get it working with Service Workers... until now.

If we are to build HTML in Workers then we need some 'DOM' in them.

Templating libraries needn't be so hard

Summary of the challenges that I beleive we developers face every day.

この記事は1年以上遅れています。それは私の草案に長年詰まっていましたが、私はそのアイデアが2018年に解決する必要があると思っています。また、昨年、他の問題も発生しています。 私はインドネシアで2016年に開発者とぼんやりとチャットをしていましたが、それはウェブがねじれている（彼らは文字通りの言葉だった）という会話の中で出てきました。この問題の要点は、今日のユーザー、特に初めてオンラインになったユーザーがサイロ内部でコンテンツを作成していることです。場合によっては、これらのサイロウェブのような外観と感じるが、これらのプラットフォームでのみ使用可能ですが、すべてのネイティブ・アプリケーションには能力があるという事実によって永続化されていますユーザーがコンピューティングデバイス上に持っているすべてのインタラクションに積極的に参加することができますが、Webはそうではなく、それがキラーです。 Webエクスペリエンスにコンテンツを取得することは不可能ですが、コンテンツを取得するのは簡単です。 より具体的には、私たちが議論したいくつかのシナリオがありました。 あなたはあなたのカメラアプリで写真を撮って、あなたは画像を共有したいと思う。あなたは共有を押しますが、ネイティブアプリだけがリストに表示されます。ウェブはユーザーのための選択肢の一部ではないため、ウェブはその価値を捕らえることはできません。 2.ブラウザで現在のページを共有したい。あなたは共有を押しますが、ネイティブアプリだけがリストに表示されます。情報を共有するという行為は、ユーザーがWebからネイティブの経験を失うことを意味します。3. Webページ内に直接コンテンツを作成して共有したい場合、唯一のオプションは共有するウィジェットを含めることです。 2017年の早い段階で、Web（ネイティブChromeのユーザー）にネイティブ共有をもたらしたnavigator.shareのリリースを見ました。皮肉なことに、 navigator.share APIはネイティブアプリを使ってユーザーの流れを永続させます。 2018年には、ネイティブのプラットフォームで永続化されているサイロをより効率的にするためにウェブを愛するでしょう。ウェブは、ユーザがデバイスとのあらゆる主要な相互作用に参加できる必要があります。 2017年の後半、AndroidのChromeで「ホーム画面に追加された機能が強化されました」が開始されました。つまり、ユーザーがあなたの Progressive Web Appをインストールするたびに、実際のAPKがユーザーのために生成されます。 Android上のAPKは、すべての目的と目的で、ウェブアプリケーションがネイティブアプリケーションとみなされることを意味します。 「ホーム画面への追加が改善されました」という最初の反復では、PWAの範囲内にあるURLへのすべてのナビゲーションがPWAで直接開かれることを意味しています。 将来は少し明るいです。 Chromeは共有ターゲットAPIで作業しています。これにより、サイトが受信に参加することを宣言できますの “株式”。これは、ユーザーがリンクを共有するたびに、あなたのPWAを一覧表示できることを意味します。 Twitter Lite（https://lite.twitter.com）のような大きなサイトでは、ユーザーがネイティブアプリを使用する必要なく共有できるようになるため、この開発には非常に興奮していますそれはまた、ほんの一握りのユーザーが使用するかもしれない小さなニッチサイトも同じエコシステムの一部である可能性があることを意味します。 APIはまだ画像やバイナリデータを扱うことができませんが、Androidエコシステムを見れば、ACTION_SENDインテントが最もよく使われるインテントであり、主にテキストとリンクを共有するためのものです。 それはスタートです。ウェブは一度に1つのサイロを分解しています。

Michael Mahemoffはウェブの可能性についてたくさん教えてくれました。 Mikeと一緒に作業する前に、私はWeb上に構築しました。リンク可能性や発見などの利点を理解しましたが、可能なことを完全に把握することはできませんでした。 マイク氏は、「Webは私のAPIです」と言って、マイクロフォーマットやその他の構造化データを使ってページ内の自分のサイトとデータを公開し、簡単なXMLHttpRequestとCORS APIを使用して、別のブラウザコンテキスト Anyway, what’s cool about this is you can treat the web as an API. The Web is my API. “Scraping a web page” may sound dirtier than “consuming a web service”, but it’s the cleaner approach in principle. A website sitting in your browser is a perfectly human-readable depiction of a resource your program can get hold of, so it’s an API that’s self-documenting. The best kind of API.

私はWeb Intentsの死を乗り越えたことはありません。私はいつもウェブに深刻な問題があると感じました。ユーザーを1つのWebサイトにロックするサイロを構築し、より豊かな経験を構築するためにアプリケーションを接続しません。私たちは別のサイトに移動するためのリンクを持っていますが、私たちのサイトで使用できる機能にはアプリケーションを接続していません。クラウドサービスから画像を選択してアプリで使用したり、ユーザーが好きなエディタで画像を編集したりできます。私たちは私たちのページをリンクする方法だけではなく、私たちのサービスをリンクしています。 Web Intentsはそれを修正しようとして失敗しました。 共有APIは、サイトとアプリケーションを相互接続するためのユースケースを1つ解決しますが、一般的にIPCとサービスの発見は解決されていません。ソリューションがあると思います…解決策はありません。私は信じられないほど興奮している実験です。 私のチームのSurmaとIan Kilpatrickは、ここ数カ月間、Tasklets APIのシムに取り組んでいました。 Tasklets APIは、Web上に軽量のマルチスレッドAPIが存在するように設計されています。 ES6クラスは「タスクレット」として公開され、メインスレッドをブロックせずに呼び出すことができます。これはUIに最適です。タスクレットAPI自体は非常に興味深いですが、最も興味深いのは、Webワーカーを使用してPolyfillを構築し、Workerで定義されたES6クラスの機能を公開する方法を開発したことです。彼らは、postMessage APIの複雑さのすべてを、JS開発者にとってきちんとしたパッケージとまともなモデルに抽象化しました。 Web Intents APIを構築した理由の1つは、postMessage APIで動作するAPIとサービスを作成する開発者の経験が非常に複雑で、postMessage APIに対処しなければならず、複雑なメッセージ処理システムおよび関連する状態機械を含む。 伝統的労働者 それはちょうど複雑です。 2つのウィンドウを相互にやりとりさせたい場合は、さらに悪化します。開いたウィンドウは、メッセージを送信し始める前に準備が整っている「オープナー」を返信する必要があります。 TL; DR - window.openは、あなたが定義したURLにナビゲートする前にabout：blankを開きます。 ウィンドウポストメッセージ体験 複数のウィンドウ間や他のウィンドウ内のワーカー間でメッセージをやり取りする場合は、さらに複雑になります。 さらに複雑な... 私はこれがクライアント側のAPIを公開する主な理由の1つだと思います。難しすぎる。 タスクレットpolyfillにはソリューションが埋め込まれていたので、Tasklets APIをシンプルなProxy APIにリファクタリングできるかどうかを尋ねるとSurmaに尋ねました。数時間後にComlinkがポップアップしました。 Comlinkは、ローカルのコンテキストでリモートクラスや関数をインスタンス化しているように見えるAPIにMessageChannel APIとpostMessage APIを抽象化する小さなAPIです。例えば： ウェブサイト const worker = new Worker('worker.js'); const api = Comlink.proxy(worker); const work = await new api.HardWork(); const results = await work.expensive(); ウェブワーカー class HardWork { expensive() { for(let i = 0; i < 1e12; i++) sum += /* …omg so much maths… */ return sum; } } Comlink.

Building Progressive Web Apps progressively is possible. This is how I did it.

最近のプロジェクトでは、Webプッシュサービスを構築する際に、アプリケーションレベルのイベントに応じてUIを応答させたいと思っていました。システムには依存しておらず、ビジネスロジックとは独立して自分自身を管理できるようにしたいと考えていました。 私は多くのさまざまなツールを見て回っていましたが、NIH症候群が頻繁に起こり、人々が自分たちのインフラストラクチャ要素をかなり早く実装できると思うという事実が頻繁にあるため、サイドPubSubサービス＆mdash;それは私の必要性のためにかなりよく働いた。 カスタムDOMの「イベント」を使用し、DOMが既に開発者に提供している既存のインフラストラクチャを使用する必要があるかどうかを議論しました。 addEventListenerを使ってイベントを処理し、イベントを消費する機能。唯一の問題は、EventTargetで継承または混合するモデルを持つことができないため、DOM要素またはウィンドウからイベントハンドラをハングする必要があることでした。 _ 考え方： EventTargetをオブジェクトとして使用すると、カスタムPubSubシステムを作成する必要がなくなります。 この制約を念頭に置いて、何かをコーディングする意志と私が自分で作ったバグを気にしない傾向があるので、私は大まかな計画を描いた： /* When a user is added, do something useful (like update UI) */ EventManager.subscribe('useradded', function(user) { console.log(user) }); /* The UI submits the data, lets publish the event. */ form.onsubmit(function(e) { e.preventDefault(); // do something with user fields EventManager.publish('useradded', user); }) このすべては新しいものではありません。 Reduxと他の多くのシステムではこれがすでに行われており、多くの場合、状態の管理にも役立ちます。私の頭の中では、私は実際にブラウザに既に状態にseptateモデルを必要とする状態を持っていません。 実装は非常に簡単で、抽象化は私にとっては非常に便利です。 var EventManager = new (function() { var events = {}; this.publish = function(name, data) { var handlers = events[name]; if(!

もう1週間、ChromeのCanaryチャンネルにあるShape API経由の顔検出についてお話しました。現在、バーコードの検出はChrome Canaryでも行われています（Miguelは私のヒーローです）; バーコードは巨大です！彼らは我々が購入するほとんどすべての製品にあります。多くの悪意を持ったQRコードは、米国とヨーロッパ以外の国でも巨大である。バーコードとQRコードは、メディアとあなたとの間で少量のデータを転送することによって、物理世界とデジタル世界をつなぐ簡単な方法を提供します。これはデスクトップの時代には莫大な量の使用ではないかもしれませんが、モバイルの時代にはそれは重要です。このデータにアクセスするためだけにアプリをインストールする必要はありません。 シェイプ検出APIは、ユーザーのデバイスの下にあるハードウェア機能の上に標準インタフェースを作成し、主に顔検出とバーコード検出という新しい機能セットをWebプラットフォームに開くため、面白いです。 バーコード検出APIは、現在WICGにあるShape Detection APIに基づいています。 wicg /）は、インキュベーションおよび実験段階にあることを意味する。 Androidではさまざまな1Dおよび2Dのバーコードを検出できますバーコード： 1D barcodes: EAN-13, EAN-8, UPC-A, UPC-E, Code-39, Code-93, Code-128, ITF, Codabar 2D barcodes: QR Code, Data Matrix, PDF-417, AZTEC さらに： It automatically parses QR Codes, Data Matrix, PDF-417, and Aztec values, for the following supported formats: URL Contact information (VCARD, etc.) Calendar event Email Phone SMS ISBN WiFi Geo-location (latitude and longitude) AAMVA driver license/ID Shape Detection APIは現在Chrome Canary（M57）にあり、 chrome：// flags /＃enable-experimental-web-platform-featuresで有効にする必要があります

私は最近、[FFMPEG.js]を使ってAndroidデバイスからスクリーンキャストしてデバイスフレームにビデオをラップするというProgressive Web Appを作成しました（https ：//github.com/Kagami/ffmpeg.js）ように： また、building ffmpeg.jsを整理して、比較的容易にffmpegのカスタム最適化ビルドを作成できるようにしましたブラウザで実行します。 私が考えている2つのことは、オーディオとビデオの操作に関してWebができると思うものを押し進める、新しい小さなプログレッシブなWebアプリケーションを構築する機会がたくさんあると思います。 Web上には多くのWebベースのビデオユーティリティがありますが、私の目には多くのものが古いWebサイトのように構築されており、クライアント側の処理の進歩を利用せず、広告を積んでいてオフラインで作業することはできません。 私は、Unixの哲学である「一つのことをやって、うまくやる」（https://en.wikipedia.org/wiki/Unix_philosophy#Do_One_Thing_and_Do_It_Well）を大変盛り込んでいます。簡単かつ迅速に構築できるさまざまなWebアプリがたくさんあると思う： *ビデオをトリムする（前面から5秒掛かる、バックから3秒かかるなど）*すべてのビデオフォーマット - > GIF *たくさんの画像 - >任意のビデオフォーマット*任意のビデオフォーマット - >任意のビデオフォーマット*ウォーターマークの追加*ビデオのサイズ変更*ビデオを縮小する*ビデオにウォーターマークを加える*お互いの上にビデオを重ねるビデオを一緒にスプライスする FFMPEGプレイグラウンド（ソースとスクリプトをドロップする）* アイデアがあればこのリストに追加する 私は私のDevice Frames repo on Githubを使ってこのためのUIハーネスとしてコードの大部分を整えていると思います。多くの場合、それは調整の問題ですffmpeg処理グラフといくつかの設定を可能にするためにUIを更新する。 誰かが参加したいと思ったら、今後数週間にわたってこれらの2つを作成し、連絡を取り合おうと思います！

FFMPEG.jsはすばらしいプロジェクトです。私の最新プロジェクト「Device Frame」（https://paulkinlan.github.io/）の構築に役立ちました。 deviceframe.es/）。これは基本的にffmpegを構築します（サイズを小さくしておくためのデフォルトの良いセットを使用しています）。デフォルトのビルドが必要なフィルタとエンコーダをサポートしていない場合は、それを自分で構築する必要があります。 これは私の将来のメモですが、これは私がそれを働かせるためにしたものです。 （注：私はmacOS sierraを試して、コンパイルエラーを起こしていました）。 ####インストールDeps sudo apt-get install automake libtool build-essential cmakeを実行します。 ffmpeg.jsをダウンロード git clone git@github.com：Kagami / ffmpeg.js.git 2.cd ffmpeg.js 3. git submodule init 4.git submodule update --recursive ####インストールEmscripten： Linux：ダウンロード2. ./emsdk update 3../emsdk install latest4.待って… 5../emsdk activate latest 6. ソース。/ emsdk_env.sh ####ビルドffmpeg.js すべてを作る fribidiにエラーがある場合： cdビルド/ fribidi / && ./bootstrap && configure 次のようなエラーが表示されることがあります。 ./configure: line 4255: syntax error near unexpected token `2.