日本語訳があるので面倒臭がらずに読んだほうがいいです。 要約 AMPは無意識にユーザーがGoogleエコシステムに留まるようになっており、また検索結果に対してプレミアムな演出や優先順位を与えており、Webの中立性を破壊している、という指摘。 Googleが言うように、Webの速さが懸念ならば、AMPという技術の有無に関わらず特定の速度を満たせば今のAMPと同じような特典を与える、また明示的にGoogleのエコシステム内にいるという演出(おそらくヘッダーを付与するなど)を行う、といった提案。 私見 GoogleのWebの速さに対する懸念も、AMPの実装の邪悪さも、自分は両方よく分かる。 AMPは自分の仕事のドメインとしてチェックしているが、プラグインがGoogleのホワイトリストとして管理されていて、実際には政治力を使って、プラグインを登録させるといったアクションが必要になり、日本のような狭

4ヶ月ほど前、 Flow & Redux で Reducer の実装パターンを考える という記事を書いたが、 reducer を型付けするという目的は達しているものの、明らかに記述量が増えて冗長だという問題があった。 ところでこういう記事を見つけた。 これを flow 向けに書き直した、というかセマンティクスが一緒だったので、そのまま動いたのだが、これを自分向けに書き直したらとてもいい感じになった. flow は v0.54.1 コード // @flow type __ReturnType<B, F: (...any) => B> = B type $ReturnType<F> = __ReturnType<*, F> // Actions const INCREMENT = 'counter/increment' const ADD = 'counter/add' export func

某所で使った資料の公開版 用語整理 PWA: ネイティブアプリのようなUXを提供するための機能群 SPA: JSで遷移するシングルページアプリケーション AMP: 後述 PWAMP: AMPで流入させてPWAを起動する形式 MFI: モバイルファーストインデックス いまさら聞けないPWAとAMP アメブロ2017: Isomorphic Web Appの進化編 AMP とは イニシャルビューのためのHTMLの特殊なサブセット GoogleにホワイトリストされたHTML属性しか使えない GoogleにホワイトリストされたJSプラグインしか使えない CSSはHEADに全部書く AMP仕様を満たすと、Googleがキャッシュして、モバイルの検索流入ではそのキャッシュを使う HTTPS必須 必ずしも全ページをAMPに対応する必要はない PWA: ServiceWorker の機能 リソースの先読み

このドキュメントの目的 自分は趣味でFlowをずっと使っていて、またプロダクションでも今まで3プロジェクトほどにFlowを導入した。その知見。 「Flow は便利そうだけど、怖い」「いれてみたら色々ハマったからクソ」「わからん、なにもかも…」という人に対し、自分がいままで出くわしたパターンや、聞かれた疑問について、メジャーな解法を提示する。 なぜFlowを導入するか Babel から段階的に導入することが出来る React の JSX にも推論を入れることができる 部分的に適用できる ASTがES準拠であり、ESLintなどがツールが使える(TSは独自AST) それ自身ランタイムに全く影響はないので落とすのも簡単 実際にはReactと一緒に使うのが、エコシステムもユースケースも揃っていて、一番効果を発揮するだろう。それか、小さい npm モジュールを自分で書くとき。 型のメリット/デメリッ

Yarn とは 名前から yet another ... な雰囲気を漂わせてますが、 npm互換 です。(追記: 正確にはnpmの生成するpackage.jsonと互換とのことだった)。各所から node連中はまたツール増やしやがって！という雰囲気を感じるので、ここは明確にした方がいい。(techcrunchの記事とかそういう印象を与える書き方になってる) npm install 時のディレクトリ配置への介入 npm install 時のより賢いローカルキャッシュ yarn.lock ファイルでバージョン固定 yarn 環境下で yarn add, yarn install などを行った場合、 yarn.lock と package.json に同時に書き込み、 その環境で生成されたファイルは yarn なしでも動きます。つまり、yarn はより厳密に npm のバージョンを固定したい人向