A quick dive in to how to use Lighthouse to try and understand how users in a country might experience the web.

Ruth JohnがChrome OSに移行しました（一時的に）：

The first thing, and possibly the thing with the least amount of up to date information out there, was enabling Crostini. This runs Linux in a container on the Chromebook, something you pretty much want straight away after spending 15 minutes on it.

I have the most recent Pixel, the 256GB version. Here’s what you do.

• Go to settings.
• Click on the hamburger menu (top left) - right at the bottom it says ‘About Chrome OS’
• Open this and there’s an option to put your machine into dev mode
• It’ll restart and you’ll be in dev mode - this is much like running Canary over Chrome and possibly turning on a couple of flags. It may crash, but what the hell you’ll have Linux capabilities ��
• Now you can go back into Settings and in regular settings there’s a ‘Linux apps’ option. Turn this on. It’ll install Linux. Once this is complete you’ll have a terminal open for you. Perfect

全文を読む

彼女の主なマシンが壊れたので、ルースはChrome OSに移行するという大きな記事を書いています。

私は4ヶ月前（Google I / Oの前）にChrome OSにフルタイムで移行し、PixelBookを壊したためにMacに移行しました（現在は修正済み）。

私のために、それは今日そこにある最高のウェブ開発機の一つです。それは私が ‘真のモバイル’をテストできる唯一のデバイスです - あなたはそれにARCプラットフォームを介して、モバイル、サムスンのブラウザ、ブレイブなど、モバイル上のモバイルをインストールすることができます。 CrostiniはChrome OSのゲームチェンジャーでもあります.Chrome OSにLinux Appエコシステムの多くをもたらし、Chrome OS上で私にとって巨大なアプリケーションギャップを埋めるようになります。私はFirefox、vim、git、VSコード、ノード、npm、すべてのビルドツール、GIMP、Inkscapeを持っています…それは完璧だとは言えませんが、Crostiniはもっと速くて、GPUはまだ加速していません。 Filemanagerなどとの統合がさらに進んでいき、最終的にPixelBookには物理的なポートがさらに必要になります.2つの4kスクリーンを接続することはできますが、同時に充電することはできません。

私はルースのまとめも非常に正確だと思うが、PixelBookは高価なマシンだが、これはますます多くのデバイス（特に低価格帯のデバイス）になることを非常に喜んでいる。

Would I pay full price for it? I’m not sure I would pay full price for anything on the market right now. Point me in the direction of a system that will run my graphics software and makes a good dev machine (with minimal setup) and lasts more than 18 months, point me in the direction of a worthy investment and I will pay the money.

うん。

PWA。プログレッシブウェブアプリ。 Frances BerrimanとAlex Russellは、2015年に「プログレッシブウェブアプリ：私たちの魂を失うことなくタブを逃れる」（0）という、「プログレッシブウェブアプリ」という言葉を主張しています。 3年後、我々は長い道のりを歩んだ。当初は1つのブラウザエンジンでしか実装されていなかったサービスワーカー、マニフェスト、ホーム画面に追加、Web Pushというゆるやかな技術の集まりから、企業や開発者と業界全体に密着し始めたブランド、ブラウザベンダーは大多数の ‘PWA’スタックを実装しています。 野生のPWAの数を大まかに把握するのに役立つappディレクトリ、toolsがあります。 PWA]（3）。しかし、PWAは何を定義していますか？フランシスとアレックスはこの特徴のリストを思いついた： Responsive: to fit any form factor Connectivity independent: Progressively-enhanced with Service Workers to let them work offline App-like-interactions: Adopt a Shell + Content application model to create appy navigations & interactions Fresh: Transparently always up-to-date thanks to the Service Worker update process Safe: Served via TLS (a Service Worker requirement) to prevent snooping Discoverable: Are identifiable as “applications” thanks to W3C Manifests and Service Worker registration scope allowing search engines to find them

ムスタファは次のように書いている。

Tooling is complicated, we are a tooling focused industry, and they change so much. I have used maybe rough eight different tools, from Photoshop to Sketch. That’s before we add prototyping tools to the mix. This may be something we just have to accept. After all, type standards only really started to settle in the 90s, and typography is a 500-year-old discipline.

Designers are still finding it difficult to prove the importance of the process. I think this is something that we have to take on board: to learn how to educate and not just expect everyone to trust us by default. That takes time — perhaps using scenario-based design or design workshops like a design sprint would help. Getting non-designers to observe users while using a prototype they created is one of the best experiences I have seen in this field.

Cross-browser support is lacking crucial features. Designers need to understand developer tooling, to better scope out what is possible. I think using paired programming or the design process described above can help.

Responsive design is still challenging. I think this is in part due to the tools we use; I would love Chrome Design Tools that would help turn the browser into a creative tool. This space is where I think the next evolutionary step for site and web app creation is at. Mozilla is doing some fantastic work in this space, with their layout and shapes tooling.

All in all the challenges that we face seem to be all the age-old ones. Process, tools, and respect.

全文を読む

私はこれを非常に興味深い投稿と見なしました。これは、ウェブ開発者の課題について書いた記事の補足でもあります。ブラウザの互換性が問題であることは驚くべきことではありませんが、まだ懸念されるのは、IE11を構築することはまだ業界を後押ししていることです。同様に、Mustafa氏は、レスポンシブデザインのツールにはまだ問題が残っていると指摘しています。また、単一のレスポンシブルなソリューションに重点を置くと、常にムスタファのポストにあります。

Designing once and using everywhere is still hard to reach ambition.

これは私たちがまだ苦労していると思う問題です。一方では、誰もがすべてのデバイスのフォームファクターで誰にでも役立つことができる応答性の高いソリューションを構築したいと考えています。一方、ユーザーコンテキストは重要であり、しばしば特定の時間に特定のアクションを実行するだけです。小売業や商工業では多くの人々が見ています。人々はモバイルでブラウジングしてデスクトップで完成し、このマルチモーダルモデルをより多くの人に提供したり、すべてのデバイスで一貫した体験を構築したりできます。その答えは「それは依存している」と疑われますが、製品チームからエンジニアリングチームまで、誰にとっても難しい問題のいずれかです。

Philip Walton氏は、ブラウザがタブをアンロードしたときの対応方法をChrome開発者がコントロールするために、Chromeチームが取り組んでいる新しいAPIについて深く掘り下げています。

Application lifecycle is a key way that modern operating systems manage resources. On Android, iOS, and recent Windows versions, apps can be started and stopped at any time by the OS. This allows these platforms to streamline and reallocate resources where they best benefit the user.

On the web, there has historically been no such lifecycle, and apps can be kept alive indefinitely. With large numbers of web pages running, critical system resources such as memory, CPU, battery, and network can be oversubscribed, leading to a bad end-user experience.

While the web platform has long had events that related to lifecycle states — like load, unload, and visibilitychange — these events only allow developers to respond to user-initiated lifecycle state changes. For the web to work reliably on low-powered devices (and be more resource conscious in general on all platforms) browsers need a way to proactively reclaim and re-allocate system resources.

In fact, browsers today already do take active measures to conserve resources for pages in background tabs, and many browsers (especially Chrome) would like to do a lot more of this — to lessen their overall resource footprint.

The problem is developers currently have no way to prepare for these types of system-initiated interventions or even know that they’re happening. This means browsers need to be conservative or risk breaking web pages.

The Page Lifecycle API attempts to solve this problem by:

• Introducing and standardizing the concept of lifecycle states on the web.
• Defining new, system-initiated states that allow browsers to limit the resources that can be consumed by hidden or inactive tabs.
• Creating new APIs and events that allow web developers to respond to transitions to and from these new system-initiated states.
• This solution provides the predictability web developers need to build applications resilient to system interventions, and it allows browsers to more aggressively optimize system resources, ultimately benefiting all web users.

The rest of this post will introduce the new Page Lifecycle features shipping in Chrome 68 and explore how they relate to all the existing web platform states and events. It will also give recommendations and best-practices for the types of work developers should (and should not) be doing in each state.

完全な記事を読む

私の最初のコメントは、あなたがフィリップスの記事を読むべきだということです。それは信じられないです。

モバイルでは、ユーザーがブラウザを使用していないときにリソースを節約するために、ページをバックグラウンド（フリーズまたは破棄）するときにかなり攻撃的になる可能性があります（タブを入れ替えたり、AndroidのChromeアプリから移動するなど）あなたは伝統的にこれがいつ起こるのかを知らない開発者としてページを開いて、簡単に状態を保持したり、開いているリソースを閉じたりすることができず、アプリケーションが重要なときに状態をきれいに再水和します。開発者がコントロールできるようになると、情報に基づいた選択を行うことができ、ユーザーや開発者のエクスペリエンスに深刻な影響を与えることなく、ブラウザをより積極的に使用してリソースを節約できます。

最後に、下の図はそれをすべてうまく説明しています。

Pete LePageは、Chromeのホーム画面に追加するという重要な変更について書きます

Add to Home Screen changes

If your site meets the add to home screen criteria, Chrome will no longer show the add to home screen banner. Instead, you’re in control over when and how to prompt the user.

To prompt the user, listen for the beforeinstallprompt event, then, save the event and add a button or other UI element to your app to indicate it can be installed.

全文を読む

多くの人が beforeinstallpromptイベントを処理していないので、Web APKのインストール数が急激に減少することを意味していたため、これは元々気になりましたが、実際には正しいことだと思います。

目標はWeb上で起こっている迷惑なプロンプトの数を減らすことです。業界で最後に必要となるのは、ユーザーがPWAをインストールしたいと思ったときに表示される比較的大きなプロンプトです。あなたがいつどこで**あなたがインストールを促すかを考えて、あなたはユーザージェスチャーに応じてそれをしなければなりません。

きちんとしたことは、私たち（Chrome）が、体験をインストールできることをユーザーに知らせるためのより多くの周囲の方法を導入していることです。最初の負荷に現れる小さなボトムバーです。ユーザーに行動を起こせることを知らせるより微妙な方法。

PinterestのPWAの概要

The verdict

Now for the part you’ve all been waiting for: the numbers. Weekly active users on mobile web have increased 103 percent year-over-year overall, with a 156 percent increase in Brazil and 312 percent increase in India. On the engagement side, session length increased by 296 percent, the number of Pins seen increased by 401 percent and people were 295 percent more likely to save a Pin to a board. Those are amazing in and of themselves, but the growth front is where things really shined. Logins increased by 370 percent and new signups increased by 843 percent year-over-year. Since we shipped the new experience, mobile web has become the top platform for new signups. And for fun, in less than 6 months since fully shipping, we already have 800 thousand weekly users using our PWA like a native app (from their homescreen).

Looking back over one full year since we started rebuilding our mobile web, we’re so proud of the experience we’ve created for our users. Not only is it significantly faster, it’s also our first platform to support right-to-left languages and “night mode.” Investing in a full-featured PWA has exceeded our expectations. And we’re just getting started.

全文を読む。

これは本当に素晴らしいポストショーで、質の高い、迅速で魅力的なサイトを構築する利点があります。 PWAの ‘App’部分、具体的には ‘Add to Homescreen’のインストール可能性が多くのユーザーによって使用されていることもわかります。より広範な記事を読んだことは、彼らが素晴らしいウェブサイトの経験に焦点を当てていたことを知っていることです。つまり、コード分割による繰り返し可能で予測可能なパフォーマンスを持つ高速ロードサイトに焦点を当てています。チーム。その後、ベースエクスペリエンスがあれば、プッシュ通知などの機能を必要とするユーザーに重ねることができます。

デフォルトでは、Hugoは正しいコンテンツタイプの.mjsファイルを提供しません。実際、最近までhugoはMIMEタイプごとに複数のファイル拡張子を提供することはできませんでした。これは修正されたv0.43のように見えます。

[mediaTypes] [mediaTypes.“text/javascript”] suffixes = [“js”, “mjs”]

全文を読む。

上記のコードでは、正しいMIMEタイプのESモジュール用のmjsファイルを提供できます（メモモジュールは ‘text / javascript’で提供する必要があります）。これはローカルテストにのみ必要です。ホスティングは別の問題です:)

私はESモジュールについて昨日投稿した投稿を考えています

I needed a quick way import a simple module get-urls into my project. The module is well tested and it does what I needed … ignore the fact that it’s pretty easy to implement in a couple of lines of JavaScript. The problem I had is that my project is built in ES6, uses modules and I didn’t want to have to bundle up using CommonJS (require).

I couldn’t find a lot of guidance on what to do here, so I went to experiement and this solution is the solution I came across:

1. Create a file that imports the npm module I needed. module.exports = require(‘get-urls’); This module will be what’s converted to ES6 style.
2. Create a rollup config that
   1. Imports the node globals, and builtins.
   2. Resolves all npm modules required for my usage of this module.
   3. Pass the results through the commonjs plugin so that it’s now in JavaScript module format.
   4. Compress the output, because it’s huge :
3. Include the bundled file in your project and rejoice.

全文を読む。

私が元の記事で試してみたかったことの一つだが、私が取り上げることにしたのは、ノードのエコシステムには膨大な量のコードがあり、それは実際にはノードそのものに固有のコードではないが、 Common JSや他の非常に特殊なNode API（バッファ、古いURLなど）を介してNodeを起動すると、ESモジュールをユビキタスにするために必要な変更が必要になる可能性がありますさまざまなプラットフォーム（Web /サーバー）でコードをきれいに共有できるようにするために、多くの変換ツールとバンドルを使用する必要があるエコシステムが変わります。

私たちはどこにいるのですか、Web上での話がありませんでした.Nodeが導入したプリミティブのヒープがなかったので、実際には多くのプラットフォームの要件が考慮されるようになりました。状況の批判よりも多くの肯定的な評価。

また、ノードとウェブの両方で標準的なファイル拡張子として ‘.mjs’を使用する動きもあります。しかし、私はこれを完全に快適に感じていますが、.msjはインフラストラクチャがまだ「text / javascript」と認識しているファイルではなく、これをソートして惑星上のすべてのWebサーバーによって自動的に推測されることを楽しみにしています。私は、サービングインフラストラクチャにさらに多くの構成変更を展開する必要はありません。

楽しい時間がたくさんあります。私は1つはWebにもっと多くの機能をもたらすことを楽しみにしています。

私は静的なサイトにコンテンツをプッシュするのを簡単にする方法に取り組んできました。もう1つのポストでもっと共有することは楽しい小さなエクササイズでした。この記事では、ほぼすべてのnpmモジュールをJavaScriptモジュールを使用してフロントエンドプロジェクトにインポートするために使用した rollup設定を共有したいと思います。 私はプロジェクトに簡単なモジュール get-urlsを簡単にインポートする必要がありました。モジュールは十分にテストされていて、私が必要なことをしてくれます… JavaScriptの2行で実装するのはかなり簡単だという事実を無視してください。私が持っていた問題は、私のプロジェクトがES6でビルドされ、モジュールを使用していて、CommonJS（ require）を使ってバンドルしたくないということでした。 私はここで何をすべきかについて多くの指針を見つけることができませんでしたので、私は実験に行きました。このソリューションは私が遭遇した解決策です： 1.必要なnpmモジュールをインポートするファイルを作成します。 module.exports = require（ 'get-urls'）;このモジュールはES6スタイルに変換されます。 2.ロールアップ設定を作成します。1.ノードのグローバルと組み込み関数をインポートします。 1.このモジュールの使用に必要なすべてのnpmモジュールを解決します。 1.結果を commonjsプラグインに渡して、JavaScriptモジュール形式になるようにします。 1.巨大なので、出力を圧縮します：\ 3.あなたのプロジェクトに同梱のファイルを含めて喜んでください。 import resolve from 'rollup-plugin-node-resolve'; import commonjs from 'rollup-plugin-commonjs'; import builtins from 'rollup-plugin-node-builtins'; import globals from 'rollup-plugin-node-globals'; import closure from 'rollup-plugin-closure-compiler-js'; export default { input: 'static/javascripts/get-urls.js', output: { file: 'static/javascripts/get-urls.bundle.mjs', format: 'es', browser: true }, plugins: [ globals(), builtins(), resolve({ preferBuiltins: false, browser: true, // pass custom options to the resolve plugin customResolveOptions: { moduleDirectory: 'node_modules' } }), commonjs(), closure({ compilationLevel: 'WHITESPACE', languageIn: 'ES6', languageOut: 'ES6' }) ] }; おそらくこれよりも良い方法があると思いますが、比較的シンプルな関数（70kb）の出力は出力されますが、ここでは自分のページにnpmのモジュールを直接使用できます。

This DotのTracy Leeは、ブラウザのベンダーの多くが取り組んでいることの概要を示すために、かなりきれいなライブストリームを編成しました。

Browser representatives from Brave, Beaker, Edge, Chrome, & Mozilla get together to talk about recent updates and the state of browsers.

Featured Speakers:

• Brendan Eich -  Creator of Javascript, Co-founder & CEO at Brave Software
• Paul Frazee - Works on Beaker Browser
• Matthew Claypotch - Developer Advocate at Mozilla
• Paul Kinlan - Senior Developer Advocate at Google
• Patrick Kettner - Edge at Microsoft
• Amal Hussein - Senior Open Web Engineer at Bocoup
• Tracy Lee - GDE, RxJs Core Team, This Dot Co-founder

全文を読む

私はライブストリームを徹底的に楽しんだし、みんなが何をしているか聞くのは素晴らしいことだった。私はBeaker Browserが分散型Webのために持っているビジョンが大好きです。私たちが最後に会って以来、多くの仕事をしてきました。

リンクされたビデオを見ることをお勧めします.Edgeには、フルService Workerサポート、可変フォントなどの膨大なアップデートがあり、WebPも導入しています。 MozillaはWebアセンブリと開発者向けツールに非常に重点を置いており、Beakerは驚くほどのことをしています。分散コンピューティングとBraveはBATに沿って動き出しています。

私たちのチームが現時点で行っている作業に焦点を当て、ディスカバリー、スピードと信頼性、UIレスポンス、UX - 物事を遂行し、セキュリティとプライバシーを概説しています。もう少し具体的には：

*ディスカバリー - インデクサーやエンベッダーなどのヘッドレスサービスでレンダリングするJSを使用して開発者がサイトを構築しやすくする必要があります。つまり、インデクサの仕組みとそのテスト方法、そして優れたSSR体験を構築する方法について、開発者を教育することに焦点を当てる必要があります。 スピードと信頼性 - すべてのサイトは、メディアンデバイス（MotoG 4/5）上で3gネットワーク上のTTIを5秒以下にする必要があり、FID（最初の入力遅延）を最適化する必要があります。 FIDは新しいメトリックなので、ユーザーが野生でサイトをどのように体験しているかを表現することを意図していることを理解しておくことが重要です.TTIは測定が難しく、FIDを簡単にする必要があります。あなたがFIDをテストするのに使うことができるpolyfillがあります（github.com/GoogleChromeLabs/first-input-delay） UIレスポンス - Webはどこでも60fpsになりたいと思っています。 ＆＃x20;＆＃x2019; FLIP＆＃x2019;わかりやすく、Houdiniを構築することで、開発者にレンダリングのエンゲージメントをより詳細に制御できるようになり、img.decodeなどのツールを使用してできるだけ多くの作業をできるだけ動かそうとしています。使いやすい。 * UX - 成果を上げよう - 我々はプラットフォームに来る新機能について話をする方法を本当に変えたいと思っています。具体的には、ユーザーエクスペリエンスを向上させるためにテクノロジを効果的に使うべき場所を示して、できるだけ中断することなく*セキュリティとプライバシー - 私は、AppleのIntelligent Tracking防止がWebに長期的な影響を与えると考えており、開発者はWebサポートのプライバシーを構築することについてもっと考え始める必要があります。もし何かGDPRがEUのウェブを「面白い」経験にしているならば。

最後に、誰もがWeb Intentsを返そうとしていると聞いて、謙虚さと心温まるものでした。

Sam Thorogoodからのメッセージ：

You’ve designed a webapp, built its code and service worker, and finally added the Web App Manifest to describe how it should behave when ‘installed’ on a user’s device. This includes things like high-resolution icons to use for e.g. a mobile phone’s launcher or app switcher, or how your webapp should start when opened from the user’s home screen.

And while many browsers will respect the Web App Manifest, not every browser will load or respect every value you specify. Enter PWACompat, a library that takes your Web App Manifest and automatically inserts relevant meta or link tags for icons of different sizes, the favicon, startup mode, colors etc.

全文を読む

私はこの図書館に驚いていました。もう少し注目を集めることができてうれしいです。私が実際にiOSのスプラッシュスクリーンを見たのは、この5年間で初めてでした。彼はデバイスの正確な画面サイズに基づいてオンザフライで画像を生成し、base64は画像をエンコードします…それはまた、SafariのAdd To Homescreenストーリーのギャップの残りの部分をいっぱいにします。

あなたがPWAを構築しているなら、それを含めるでしょう。

Font Playground is built for three groups of audiences.

The first group of audience is typographers and designers, who would like to play with fonts that are built with the latest font technologies, such as variable font. It is a playground to fully explore what these new font technologies can offer and how they can be beneficial to your creative workflow.

The second group of audience is me, as a Type Tool’s UI/UX designer. This is a playground for me to test UI experiments for variable fonts and other new upcoming font technologies. One of the key points to the success of new font technology is adoption by design tools, and furthermore, designers. How can design tool present variable fonts in a way that is useful but not too complicated to handle? I hope to find the answers with this playground.

The third group of audience is the type designers and foundries. This is a place to showcase the work-in-progress, cutting-edge font creations. It is a playground to see how fonts are being presented and used in future design tools. How fonts are used can also inform how fonts are made, and what standard should be defined.

全文を読む

これは可変フォントの素晴らしい紹介であり、実際に変化する可能性のあるものすべてをすばやく見るための素晴らしい遊び場です。すぐに着陸するように、複数のテキスト行を追加するように見えます。

注：私はこれが完全に可変フォントをサポートしていないため、Firefoxではまだ動作しないと思います。

PatrickはDid.txtについて書いています

Time flies by when you’re learning how to code. Its super important to take a second every once in a while to simple write down what you did during the past mental sprint. Writing down what you learned solidifies the knowledge.

全文を読む。

これは、私たちが内部で行うことから何百万マイルも離れているわけではなく、「スニペット」という概念を持っています。それはあなたの管理方法ですが、自分が行ったことを把握するうえで優れた方法ですが、チーム全体で共有することで、同僚、マネージャー、レポートがやっていることをよく知ることができます。

私が好きなモデルは、毎週の要約を「私がやったこと」と「今週何をするつもり」に分けることです。それは同時に私が反映し、計画するのに役立ちます。

CSS TricksのAtishay Jainは、私の心の近くの領域について書いています。

Hyperlinks are the oldest and the most popular feature of the web. The word hypertext (which is the ht in http/s) means text having hyperlinks. The ability to link to other people’s hypertext made the web, a web — a set of connected pages. This fundamental feature has made the web a very powerful platform and it is obvious that the world of apps needs this feature. All modern platforms support a way for apps to register a URI (custom protocol) and also have universal links (handling web links in an app).

Let’s see why we’d want to take advantage of this feature and how to do it.

全文を読む。

これは、アプリやサイトで利用できるさまざまなタイプのハイパーリンクのすべてをカバーするすばらしい記事でした。私はWeb IntentsとWeb上での高度なリンクの状態がたいへん残っているので、これまでずっとこの空間について多くの研究を行ってきました。

私がウェブを愛している理由の1つは、リンクの背後にはリソースへの直接アクセスがあるということです。リンクと実際のリソースを同じ方法で組み合わせることができる他のプラットフォームはわかりませんが、もっと。標準リンクでは、状態（URL）とコンテキスト（アンカー間のテキスト）を含むVIEWインテントが基本的に提供されます。カスタムプロトコルでハックすることができますが、さらに進化する必要があります。

*より多くのネイティブスキームにアクセスできるように、registerProtocolHandlerに語彙を拡張する必要があります。*プロトコルハンドラに登録されているものはシステム全体である必要があります。 *さまざまな種類のコンテンツを開くことができ、ページをシステムファイルハンドラとして登録できるようにするために、Webサイトを用意する必要があります。 * VIEWは優れているため、サイトやアプリの機能をより効果的に理解できるように、PICK、SAVE、EDITなどのコアアクションを合意しておく必要があります。それらはより高次のセマンティクスを持つ。 Androidはこれを持っていて、Siriはそれを取得しています。両方とも ‘Intents’を使用していますが、Webもそれを持っているはずです。

これは、postMessageの狂気の負担を取り除き、他の人に機能を公開することを考えるようにするComlinkなどのメッセージングの抽象化についてとても興奮している理由の1つですそして、あなたが関数を公開すると、その関数の発見をより簡単に可能にする必要があります。それがリンクが可能にするものです。

RedfinのDanには、Webスピードの優先順位付けに関する素晴らしい記事があります：

JavaScript Is the Web’s CO2

As a web developer, I find that most problems can be solved with just a little more JavaScript. Without someone or something to force the industry to cut back, web developers will continue to make web sites that only load “fast enough” via wifi on a fast laptop.

The browser vendors can’t save us. Every time they make the web faster, web developers “take advantage” of the change by using more JavaScript.

Our industry needs Google to take a principled stand, to significantly prioritize fast-loading sites over slow-loading sites

完全な記事を読む。

これを行うことができるのはGoogle（Google）だけではありません。私は私たちのチーム（WebとChrome DevRel）が、あなたが早く始動し、その後も速く動くのを助けるためのツールと指針を提供できることを見ていますが、その後、業績は機能だと思ったのではなく、

私は、開発者がパフォーマンスの優先順位を決めることのない多くの理由（ツール、ガイダンス、明確なビジネスインセンティブ）があることをWeb開発者向けの課題に書いています）、私はダンの記事記事で書いたようにGoogleがウェブの長期的な健康のための答えであると主張しているとは思わないが、業績が良くなるのを見ている企業から来る必要がある。

This project is a musical experience built with WebGL and WebVR.

Inspired by the music track, we created an ever-changing environment composed of various geometrical shapes. These were generated procedurally in Houdini and exported to Three.js.

All visual elements are randomized differently on each viewing.

全文を読む。

私は追加する余裕がない、それは絶対に素晴らしいです。見てみな。

ディーン・ヒューム氏は最近、PWAの多くの素晴らしい仕事をしています。また、彼は新しいプラットフォームAPIの多くを探っています。この場合は汎用センサーAPIです：

The Ambient Light Sensor API provides developers with the means to determine ambient light levels as detected by the device’s main light detector. This information is available to developers in terms of lux units. If you are building a Progressive Web App and you want to style it differently depending on the light levels in the room, then this could be the feature for you. There are a number of use cases for this feature, such as a web application that provides input for a smart home system to control lighting, a “Kindle” style reading app, or even a web app that calculates settings for a camera with manual controls (aperture, shutter speed, ISO, etc.).

全文を読む。

私はChrome Dev Summim 2016でGeneric Sensor APIについて語ったので、Chromeに着陸するのはしばらく時間がかかりました（私はそれがまだフラッグの裏にあると思います）。そしてEdgeに最初に着陸したようです。周囲光センサーは、汎用センサーの上に構築された多くのAPIの1つです。ジャイロや磁力計などがあります。明るさの自動調整などのユースケースを開いたり、暗いモードのテーマに切り替えるようにユーザーに指示するなど、周囲の周囲光レベルに関する情報を得ることができます。 Generic Sensor APIの基本がWebエクスペリエンスにもたらす影響を確認することは、確かに面白いことです。

ジョナサン・フルトン、ビデオブロック：

The basic architecture concepts I wish I knew when I was getting started as a web developer

全文を読む

これは、多くのWebアプリケーションを拡張するために設計された比較的標準的なスタックの本当に素晴らしい概要を示すすばらしい記事です。また、コストを犠牲にして多くの複雑さを抽象化できるHeroku、Firebase、AppEngineなどのサービスツールとして、プラットフォームを好んでいる多くの開発者がなぜそうであるかを示しています。

GoogleデベロッパーのWebアップデートでEric Bidelmanが書いた記事：

Building for the web is a rocky adventure. It’s hard enough to build a top-notch web app that nails performance and uses all the latest best practices. It’s even harder to keep that experience great over time. As your project evolves, developers come on board, new features land, and the codebase grows. That Great Experience ™ you once achieved may begin to deteriorate and UX starts to suffer! Feature Policy is designed to keep you on track.

With Feature Policy, you opt-in to a set of “policies” for the browser to enforce on specific features used throughout your site. These policies restrict what APIs the site can access or modify the browser’s default behavior for certain features.

Here are examples of things you can do with Feature Policy:

• Change the default behavior of autoplay on mobile and third party videos.
• Restrict a site from using sensitive APIs like camera or microphone.
• Allow iframes to use the fullscreen API.
• Block the use of outdated APIs like synchronous XHR and document.write().
• Ensure images are sized properly (e.g. prevent layout thrashing) and are not too big for the viewport (e.g. waste user’s bandwidth).

Policies are a contract between developer and browser. They inform the browser about what the developer’s intent is and thus, help keep us honest when our app tries to go off the rails and do something bad. If the site or embedded third-party content attempts to violate any of the developer’s preselected rules, the browser overrides the behavior with better UX or blocks the API altogether.

全文を読む

私はこの土地がどのように見えるか興味があります。私は開発者がこれに気にしないこと、あるいは彼らに圧力がかかることを心配しています。私が[Twitterで]言ったように（https://twitter.com/Paul_Kinlan/status/1016445358401040386）、私はインセンティブについて心配し、この機能によって開発者が利用可能な多数の機能を制御できるようにする必要があります。メモリを占有したり、ページを遅くしたり、不注意に第三者の埋め込み者にユーザーのプライバシーを漏らしたりする可能性があります。たとえば、PlayストアでPWAのリストを登録していた場合、アプリの起動時に一連のポリシーが自動的に適用される可能性があります。開発者は、店舗。

私はこのAPIで何が起こるかを見てうれしく思っています。たとえそれが開発者によってチームが回帰しないことを保証するためにのみ使用されていたとしても、採用されたことを熱望しています。