ブラウザベンダによる 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 で作られているものがあります。 各ブラウザの状況 まだま
React に対する感情とかコンポーネント管理ライブラリの選定とか
コンポーネント管理できそうなライブラリの選定 ここでいうコンポーネントは HTML 要素をコンポーネントに見立てるような、近代 Web フロントエンドにおける狭義のコンポーネントです。大まかな条件は次の3点。 コンポーネント中心の開発ができること >= IE9 をサポートすること（切っても良さそうなんだけど...） 既製品・スクラッチは問わないが極端なリスクは踏めない（納期がシビア） あとは期待度や API のセンスなど、個人的な審美眼判定に依ります。 angular/angular : 2.0 が正式リリースしたらまた会いましょう jashkenas/backbone : 最近のコンポーネント管理には及ばない Custom Elements ( Polymer ) : polyfill が >= IE10サポート segmentio/deku : 振る舞いは十分だったけど、>= IE10
最近あまり使ってない、流行っていた時期もあるフロントエンドもの
最近あまり使ってない、ちょっと前の流行りもの なんとなく書いてみます。Web アプリケーション開発屋さんなので、Web サイト制作屋さんとはかなり文脈ズレると思います。 jQuery ファミリー 個人的には jQuery って、協業用のツールという位置づけでした。jQuery でさえ書かれていれば、jQuery 書ける人材のほうが外からも調達しやすいため、人員の流動にも有効と考えられる頃が確かにありました。 DOM に触れてくれるな勢の台頭 ところが昨今では AngularJS や React、その他ライブラリでも DOM 操作が大いに抽象化されていることが多く、jQuery で直接 DOM を操作すること自体が相性良くないケースが散見されます。今思えば Backbone.js くらいのころが jQuery 需要の最終ピークだったように思います。 jQuery プラグイン の需要減 jQu
Webパフォーマンスにおけるイニシャライズとランタイム
Webフロントエンド・パフォーマンス 思考整理系。 Webフロントエンドにおける3要素として、過去のセッションでは下記の3つを中心に紹介していました。 通信コスト - Networking 描画コスト - Rendering 計算コスト - Computing これらの問題は複雑に絡み合い、時として相反する関係をとります。例えば、通信コストを減らすために、視覚表現を画像からCSS3に置き換えたら、描画コストが高くなってしまいスクロールが重くなった、なんてケースは頻繁にあるでしょう。 理解の問題 この3つのコストは確かにパフォーマンスに影響を与える要因であります。しかし、その要因がWebフロントエンドのページライフサイクルにおいて、どこで影響を与えているかは表してくれません。 要因がどのような影響を及ぼしうるかという基礎的な理解と、パフォーマンスの問題に取り組むための切り口としての理解は、そ
ぼくが実際に運用していたGitブランチモデルについて
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model（上記は翻訳記事）を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
Angularそっちのけで、Vue.jsについて所感
Vue.js 軽量でパワフルなデータバインディングMVVM, vue.jsで遊んでみた - mizchi's blog を読んで触発されたので、自分も外見的に良いなと思ったポイントだけ書き留めてみます。さすがに実戦投入できていないので、そのあたりの精度は悪しからず。 サンプルコードの雰囲気 サンプルコードとか自分でちょっと触ってみたときの感触からは、以下のポイントが気に入りました。data-bidingsとかは前提として便利です。はい。 覚え切れそうな分量のAPI Class: Vue - vue.js 脳みそちっちゃいので助かります。それに尽きる。 プロパティによる宣言っぽさ Angularだとイベントハンドラ類を書くにも、$scopeに都度ハンドラを仕込んでいくのがあまり好きでないです。工夫で回避できそうですが、与えられたスタートが下記のような状態であることには変わりません。 angu
jQueryについての所感
昨今jQueryについての所感とつきあい方を考える はじめはPHPとa-blog cmsがメインだったこのブログも、いつの間にかJavaScript（jQuery）とご飯レシピブログという謎な方向への珍走を遂げています。 そんな中、個人的にjQueryとのつきあい方について色々聞いたり思ったりで、だらだらとアウトプットしてみます。オチはつきませんでした。ﾀﾞﾗｧ...('A`) ってこれ、今年の3月に大半書いていて、なぜか8月も末の今頃に加筆修正かけたので色々アレなところあったらごめんなさい！！！もったいないから公開させてください、、てへぺろ(・ω<) なぜjQueryなのか jQuery周辺のノリ（何でもjQuery・コスト感なくjQuery・jQueryスニペット信仰）などに、正直ネガティブな感情抱くこともありますが、素直な気持ちで見ればjQueryはとても効率的だと思います。Web上
フロントエンドチューニングの箇条殴り書き
普段気をつけてるよリスト "モバイルで、WebViewとブラウザのコンパチで、特にセオリー化されていないデザインモジュールのなか、装飾画像もふんだんに使うぞ系サービス開発" の文脈における、パフォーマンス確保のため気をつけてるよリスト。 よく、パフォーマンス「向上」とか「確保」とか申しますが、メンテナンスコストなどと天秤にかけて、「必要十分」のラインを狙うのが重要だと思う次第。 画像リソース 画像リソースを揃えるときのセオリ。圧縮率とか最適化とか細かいチューニングはあれど、大雑把に下記を守る。そしてImage Optim（or 相当の処理）。 JPEGはプログレッシブで画質60くらい（オレ目安） PNGは差し支えない範囲で色数をきちんと削る 50px未満のサムネイルは@2.0xなリソースにしない 案外、Androidあわせの@1.5xや@1.0xでも大丈夫なことすらある GIFアニメを入れ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
