JavaScriptよ。文明を捨て、自然に還れ。
Web ナチュラリスト フィードを眺めていたら Alex Russell 氏の新作が投稿されていた。 The "Developer Experience" Bait-and-Switch | Infrequently Noted 本来の趣旨については原文を読んでもらえばいいし、下記はこれを読んだ上で普段の考えを踏まえて脳裏をよぎったポエムである。 我々は複雑性で仕事をしている 仕事をしている、もしくはそれでお金を稼いでいる。誰もが。 私は 2012 年頃から Web の、特に Web フロントエンドの複雑性に加担している自覚がある。 Web の専門性が高まることはその技術領域に深淵な価値があることを示唆し、それに携わることの価値を相対的に向上させることができる。 私の活動そのものは些細なものだが、かくして 2018 年現在の Web はかくも複雑になることに成功し、エンジニアリングの名の下
アーキテクチャ編: SSR と CDN ( Fastly ) とユーザー依存情報の分離（新規開発のメモ書きシリーズ4）
新規開発のメモ書きのラスト シリーズだったはずなのに、色々あって前回のエントリから1ヶ月あきました。_:(´ཀ`」 ∠): 今回の話の中心は結果的に「Server Side Rendering との折り合いの付け方」と「Fastly を利用した動的コンテンツのキャッシュ戦略」です。 このシリーズの他の記事はこちら。 技術要素編: web アプリが新陳代謝を続けるための依存関係の厳選 ビルド設定編: UA に応じた最適な JS バンドルの配信と webpack との距離感 コード設計編: context による縦軸分類とレイヤードアーキテクチャ まずは全体的なアーキテクチャ像 次の図はアーキテクチャの全体像です。クライアントサイド寄りの範囲を中心に書いているため、バックエンドな Microservice 群以降がおざなりな図ではありますがご容赦ください。 主要リソースは Fastly を通じ
Web クライアントサイドのパフォーマンスメトリクス — Speed Index、Paint Timing、TTI etc...
色々なパフォーマンス指標のこと 何かを評価するときには何らかの指標（メトリクス）を定めますが、何を指標として設定してどのように測るかというのは重要です。 いわゆる KPI もそうですが、扱っている商材やビジネスのステージ（フェーズ）によっても適切な指標は変わるかもしれません。色々な指標をよく理解して引き出しを広げておくことは、状況に合わせて適切な指標を選んで改善していく過程で役立ちます。 これまでのパフォーマンス指標 過去の Web パフォーマンス界隈はバックエンドから HTML ドキュメントを返却する際の所要時間や、Web ページロード時の各イベントの発火時間を計測する方法が多く見られました。 Backend Time Browser Event Based DOMContentLoaded Page load ( onload ) 近年は特に後者の、既定のイベント発火に依存していたクラ
SPA + サーバーサイドレンダリング、そのダルさに関する私見
いわゆる SPA + サーバーサイドレンダリングがダルい 唐突ですがおさらいです。 なぜサーバーサイドレンダリング（SSR）が嬉しいかと言えば 初期表示の Critical Rendering Path を短縮できる SEO における保守信仰にやさしい（） 古いブラウザ・低性能マシンにやさしい yahoo/fluxible による SPA + Server Rendering の概観 ::ハブろぐ であり、特に SPA + SSR の文脈においては Universal Architecture による SPA + SSR は、技術的には過渡期の歪なキメラっぽさが拭いきれませんが、昨今の Web フロントエンドにしては珍しくビジネス的な説得力があります。 SSR なのでSNSや検索からの流入による初期表示が速い SPA なので回遊時のページ遷移も速い SSR なので古いブラウザでも CSS
Web サイトっぽい SPA に必要なブラウザナビゲーションのエミュレートなど
Web サイトっぽい SPA に立ち向かう 大分前の話ですが、Node学園 20時限目 今回もdots!!!!! - connpass で Client Side of なんちゃらfresh.tv としてお話した内容のうち、Web サイトっぽい SPA に関してだけこだわりを再抽出して書き留めます。 本件は、ページ全体のスクロールや頻繁なナビゲーションを伴わず、1画面におさまるレスポンシブな Web アプリを作っている場合はあんまり関係がありません。画面内の局所的な状態更新は、コンポーネントの責務分割やら何やらの設計なので実は別の話です。 総じて、Web サイトっぽいくせに大人の事情で Web ブラウザのネイティブなナビゲーションを積極的に破壊しにいくときの心構えです。 URL が変わっても最低限レンダリングできるまで画面更新を遅延させる 画面遷移に必要なのは、 URL が更新されても次の
リモートワークの勘所と限界について1年くらいの感想、組織にとっての選択肢作りの話
1年くらいリモートワークを続けてみた感想 まず当然ながら「リモートワークは生産性が高い！これこそ未来のワークスタイル！」のような感想はありません。 生産性やコミュニケーションに関連するメリット、デメリットをうまく相殺しきれれば、生活の自由度だけ向上してハッピー、と考えています。 今は自宅かレンタルオフィスのいずれかを作業場として開発などを行いつつ、本社がある渋谷には1泊2日の出張を月2回するようなペースで仕事をしています。基本は Slack でテキストチャットによるコミュニケーションをメインとしつつ、必要があれば MTG に Hangout でビデオチャットで参加します。 生産性は大して上がらない 期待していた生産性は、それほど向上することはありませんでした。 東京にさえいなければ気軽に MTG に呼び出されることもありませんし、開発に充てることが可能な時間は若干増えています。通勤時間が長
ブラウザベンダによる Flash 包囲網の現状メモ ( 2016年12月20日アップデート )
Flash の息の根がいよいよ止まりそう ※ ( 2016年7月21日 ) Firefox について動きがあったので追記しました ※ ( 2016年10月10日 ) Chrome について 8/9 付けの動きを追記しました ※ ( 2016年10月10日 ) Safari 10 の挙動について追記しました ※ ( 2016年12月20日 ) Chrome のについて 12/9 付けの動きを追記しました ※ ( 2016年12月20日 ) Edge について 12/14 付けの動きを追記しました 脱 Flash、祝 HTML5 という機運が高まったのはだいぶ前の話ですが、実際には Flash コンテンツは今もなお数多くが生き続けています。たとえばニコニコ動画のプレイヤーであったり、アメーバピグや艦これのような人気ゲームにも Flash で作られているものがあります。 各ブラウザの状況 まだま
Web Initiative Center と社内的な所信表明
4月から社内の Web Initiative Center ( 以下 WIC ) というグループで、新しい業務に取り組み始めました。社内メールに放流することを前提として書いているので、社内向けの内容です。すみません。 2016/11/03 追記: 開局6か月／900万DL突破の「AbemaTV」、急成長するウェブサービスを支えるフロントエンドエンジニアの舞台裏：CodeZine（コードジン） の取材の中でも Web Initiative Center について話をしました。 活動 Web のプロダクト品質を横断的に向上させる Web 技術を使ったチャレンジがしやすい環境をつくる この2つが活動の主旨であり、これらを通して Web によるユーザー体験を向上させることが目的です。 活動は CyberAgent 全社ではなくメディア系の部門内にひとまず限られますが、この中にはアメブロや Ameb
HTML6 でも CSS4 でもない Web 技術のゆくえ - WCAN 2015 Winter に登壇してきました
@kazumich さんにお声がけいただき、WCAN 2015 Winter でおよそ 60 分ほどのセッションを登壇してきました。32:9 のスクリーンがあるという、TED でもやるんかオイという特殊な環境でした。普段はプロジェクター的な投影なので、スクリーンの前に立つのが微妙なんですが、ここはディスプレイが壁面に大量に並んでいて自ら発光するので、部屋を暗くしなくてもテレビのように十分に見えますし前に立っても平気です。 一緒に登壇したのが @yhassy さんと @Hidehisa さんということもあり、近年まれに見る胃痛を伴う緊張を味わいながらお話させていだきました。（リアルにセッション終了後、1時間くらい胃痛がズキズキしてました） 技術的なお話でした 参加されたみなさま、メインセッションや LT に登壇された各位、ならびに運営されたスタッフの方々、ひとまずお疲れさまでございました。貴
yahoo/fluxible による SPA + Server Rendering の概観
Single Page Application + Server Rendering yahoo/fluxible を使って、Single Page Application と Server Rendering の良いとこ取りのアーキテクチャを目指す。ある程度の複雑性と引き換えに、双方の利点で双方の欠点を打ち消し合うことができるため、全体的には良好なユーザーインタラクションを期待できる構成。 なぜ Single Page Application なのか 画面遷移時するたびにJavaScript/CSS のパースと評価をしなくて良くなる 画面遷移時のトランジションを柔軟に適用できる 画面遷移をまたがった実装が可能になる（あくまで可能になるだけ） なぜ Server Rendering するのか 初期表示の Critical Rendering Path を短縮できる SEO における保守信仰
もうES6 (ES2015) でいいんじゃないか
個人プロジェクトは ES6 で書いている ブログの頻度が落ちているので、継続のための雑さな記事を醸し出す時期。 以前に es6-Kameita を紹介したときの繰り返しですが、Babel (旧名 6to5) の登場から個人プロジェクトは ECMAScript 6 で書くようにしています。仕事でも新しい開発がある予定なので、そこでもきっと ES6 を使うことでしょう。 ahomu/Talkie ahomu/Urler ahomu/Claylump ということで「もう ES6 でいいんじゃないか」という気持ちを書きます。 厳密には、ES6トランスパイラを使っていけばいいんじゃないか、という話 仕様周りは（きっと）安定してきている 世間的の大多数的には、ES6とES7の境界すらハッキリしていないであろう状況ではありますが、ES6自体は2015年中の勧告を目標に進んでいることから、それなりに安定し
npm とフロントエンドのパッケージ管理の未来
JavaScript 系パッケージマネージャの重複問題 npm は言わずもがな Node.js のパッケージマネージャだが、フロントエンド開発においては Bower も利用するのが一般的になっている。この現状の問題点は、package.jon と bower.json という似たような管理ファイルを二重で管理しなければならないということだ。 現状の使い分けをおさらいをしておくと、次のような感じになる。 タスクランナー（Grunt/gulp）・モジュールシステム（browserify/webpack）・テストスイート（karma/testem）などの開発環境系の管理が npm の主なお仕事。インストールされたパッケージは node_modules 内に展開されて、CommonJS スタイルのモジュール管理から利用する。 本題につながる話としては、ブラウザで動くライブラリの一部は npm にも
AngularJS についての所感
AgularJS に対する気持ち 所感といいつつ、主に自分がつらさとして感じていることを書く。所感シリーズとしては jQueryについての所感 も併せて読みたい。 この学習曲線の中でいうと、たぶん今の自分は Very Cool! の頂点から降りている最中くらいだと思う。そして、マサカリをふりかぶった諸兄にひとつだけ言いたいのは、共感脳を養った方がモテるということだ。 チキンハート的弁解: 以下はAngularJSに関するつらさを述べることに専念するために、美点を挙げていないだけであってAngularJSを全方位的に貶めたり、何かと比べて明確にクソだというような意図はない。 画像は AngularJS: The Best Parts · Anand Mani Sankar からの引用。X軸にある www.bennadel.com は AngularJS 大好きさん。 辛1. $scope が
Concatだけでビルドを済ませてた例（Backbone.jsとAngularJS）
Concatでどこまで戦えるのか @jxck_ browserify使ってるんだけどあんま意味ない感じになっててつらいんだよねーっていうのを昨日 @ahomu に話したら、concatで全然いけますよって言われたからさっき乗り換えた。 — Kazuhito Hokamura (@hokaccha) August 6, 2014 (＾ω＾) 全然いけますよ 依存管理をサボってconcat 以下、「依存管理に労力を割きたくない」という理由で依存管理を省略した場合に、concatだけで破綻無くビルドするためにやっていたパターンの紹介。いけますと言った手前はあるが、最終的には現場によってケースバイケースということで、どうかひとつご容赦願いたい。 Case 1: Backbone.js Backbone.jsの場合、extends に代表されるクラスベースのオブジェクト指向モデルに多少の制約が必要に
Material Design と Polymer - HTML5とか勉強会に登壇してきた
まさかのデザインに関するトーク 先日の 第49回 HTML5とか勉強会 で、Material Design と、それをWebで実践するための Polymer (Paper Elements) まわりについてお話させていただきました。 去年とか、Googler が紹介するパフォーマンス関係のわりとマニアックなトコだとかケーススタディの共有に努めたり、さらにその前もJavaScript関係のライブラリ・ツールの話をしておりました。 という流れで、エンジニア的なブランディングに終始しておりました為、今回Google I/O 現地で話を聞いてきたとはいえ、デザインに関するセッションのお話をいただいて緊張しきりでございました。 YouTube（追記） いつの間にか動画があがってました。 第49回HTML5とか勉強会「HTML5最新情報 @Google I/O」 - YouTube 小並感 なんでgr
Web Components を支えるPolyfillライブラリ
Hello 生成されるJSそのものはピュアな感じなので、たしかにbosonicを捨ててもWeb Componentsとして成り立ちそうではある。 瑣末だが、この記事を書いてる時点で試したらWeb Platform featuresのフラグをEnableにしたCanaryで、bosonic-pollyfillsがエラー吐いてる... 余談、実はえらいかも Polymerコンポーネントって、結局Polymer入れないと使えないなら、BackboneJSで使えないAngularディレクティブみたいなもんな気がしてきた。Bosonicのコンセプト、実は偉いかも。（出来る範囲は制限されるかもしれないけど） — あほむバーガー (@ahomu) June 30, 2014 結論 個人的にはふつうのPolyfillとして動いてくれるものを精査したかったのだけど、結果的に Polymer/platform
Angularそっちのけで、Vue.jsについて所感
Vue.js 軽量でパワフルなデータバインディングMVVM, vue.jsで遊んでみた - mizchi's blog を読んで触発されたので、自分も外見的に良いなと思ったポイントだけ書き留めてみます。さすがに実戦投入できていないので、そのあたりの精度は悪しからず。 サンプルコードの雰囲気 サンプルコードとか自分でちょっと触ってみたときの感触からは、以下のポイントが気に入りました。data-bidingsとかは前提として便利です。はい。 覚え切れそうな分量のAPI Class: Vue - vue.js 脳みそちっちゃいので助かります。それに尽きる。 プロパティによる宣言っぽさ Angularだとイベントハンドラ類を書くにも、$scopeに都度ハンドラを仕込んでいくのがあまり好きでないです。工夫で回避できそうですが、与えられたスタートが下記のような状態であることには変わりません。 angu
Gruntについて最新の気持ち
思いつき だいぶ前からGrunt周りというかGruntそのものへの関心が薄れゆくなか、タスク周りがやたらと充実してきたエコシステムの恩恵を、ただただ享受するにとどまっている。 業務で700行のGruntfile.jsを見かけて、SAN値をもっていかれた折に前々から感じていた疑念が表に出た。 「これ、Gruntに仕事させすぎじゃないの」 分担してもよいのでは 前述の700行のなかには、ファイルのビルドをはじめとして、ユニットテスト、E2Eテスト、ドキュメント生成、ローカルサーバー、LiveReload etc etc etc ...すべてひとつのファイルに入っていた。 (; ⁰⊖⁰) Oh... いまいち感覚的なトコロなので表現しづらいのだが、役割としてあまりにGruntfileで表現している内容がごった煮すぎるように思う。 自分の場合、テスト周りはtestemにしていて、ドキュメント生成系
フロントエンドチューニングの箇条殴り書き
普段気をつけてるよリスト "モバイルで、WebViewとブラウザのコンパチで、特にセオリー化されていないデザインモジュールのなか、装飾画像もふんだんに使うぞ系サービス開発" の文脈における、パフォーマンス確保のため気をつけてるよリスト。 よく、パフォーマンス「向上」とか「確保」とか申しますが、メンテナンスコストなどと天秤にかけて、「必要十分」のラインを狙うのが重要だと思う次第。 画像リソース 画像リソースを揃えるときのセオリ。圧縮率とか最適化とか細かいチューニングはあれど、大雑把に下記を守る。そしてImage Optim（or 相当の処理）。 JPEGはプログレッシブで画質60くらい（オレ目安） PNGは差し支えない範囲で色数をきちんと削る 50px未満のサムネイルは@2.0xなリソースにしない 案外、Androidあわせの@1.5xや@1.0xでも大丈夫なことすらある GIFアニメを入れ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
