「その書き方、古くない？」 東京きてから仲良くさせていただいている高梨ギンペイさんが共著でWeb制作系の本を出版されたということで、さっそく拝読しました。初見から「その書き方、古くない？」というオビの煽りが素晴らしいですね。 帯の煽りどおり、古い知識をいい感じにアップデートしてくれそうなコンテンツです。 HTML/CSS とその周辺知識について網羅 個々の内容はライトで読みやすい 随所にモダンなツールチェインの解説も入る アクセシビリティ・パフォーマンスとかもある 時々、急激に難解な分野が入る(!) HTML5と呼ばれた頃よりも前の時代(HTML4, XHTML!!)からのアップデートも意識された本書では、モダンなHTML/CSSの知識を、わりと基礎のほうからフォローされています。 かと思いきや、CSSアニメーションのところでGPUレンダリングの話が入ったり、総合格闘技っぽいパフォーマンス

最近あまり使ってない、ちょっと前の流行りもの なんとなく書いてみます。Web アプリケーション開発屋さんなので、Web サイト制作屋さんとはかなり文脈ズレると思います。 jQuery ファミリー 個人的には jQuery って、協業用のツールという位置づけでした。jQuery でさえ書かれていれば、jQuery 書ける人材のほうが外からも調達しやすいため、人員の流動にも有効と考えられる頃が確かにありました。 DOM に触れてくれるな勢の台頭 ところが昨今では AngularJS や React、その他ライブラリでも DOM 操作が大いに抽象化されていることが多く、jQuery で直接 DOM を操作すること自体が相性良くないケースが散見されます。今思えば Backbone.js くらいのころが jQuery 需要の最終ピークだったように思います。 jQuery プラグイン の需要減 jQu

つまり var items = [ {type : 'A'}, {type : 'B'}, {type : 'A'}, {type : 'A'}, {type : 'A'}, {type : 'B'}, {type : 'B'} ]; を ng-repeat 越しに <ul> <li ng-repeat="item in items">Aな感じの内容物</li> <li ng-repeat="item in items">Bな感じの内容物</li> <li ng-repeat="item in items">Aな感じの内容物</li> <li ng-repeat="item in items">Aな感じの内容物</li> <li ng-repeat="item in items">Aな感じの内容物</li> <li ng-repeat="item in items">Bな感じの内容物</l

Take Grunt to the Next Level — Jonathan Suh この記事を見て知ったのだが、jit-grunt というプラグインが中々よい。Just In Time ということで、タスクのロードを loadNpmTasks でまとめて最初にやる代わりに、各タスクの実行時までロードを遅延させるというもの。 npm の jit-grunt ページを見ると相当数がダウンロードされて利用者がいるようだが、検索するとあまり紹介されてないようだったので書いてみる。 効能 17個のタスクをロードしていた手元の環境に導入したところ、単純なタスクを実行した限りでは次のような実行時間の短縮が見られた。計測は例によって time-grunt だ。 Before loading tasks で 625ms かかっていて、全体では 651ms を要した。 % grunt concat:lib

違い、または付加機能 色々な周辺事情で、勢力を広げつつある Polymer さん。（つい最近、それに加担したような気もする） 「どこまでが Web Components で、どこからが Polymer なのか」を理解するためにもPolymerの機能をメモる。Polymer は色々なことを便利にしてくれるライブラリであり、差分を言い出すとキリがないので主要なポイントだけ。 <template> が自動で Shadow DOM に放り込まれる Shadow DOM内の <link> をインラインの <style> に展開 repeat のサポート {{interpolate}} のサポート <element> のかわりを <polymer-element> としてサポート on-click とかイベントハンドラの宣言 this.$ による idが付加された要素のコレクション observe に

Google I/O に合わせたpolymer-project.orgの刷新ついでなのか、挙動の怪しかったDesignerが改善していたのでちょっと触ってみた。 Polymer Designerは、Polymerで作られたコンポーネントを、ブラウザ内のGUIでマッシュアップして新たなコンポーネントを作成することができます。 今度こそ、こういうWeb Componentsなノリで、デザイン＆開発のワークフローが変わったら良いなという期待を込めて。コンポーネントを積み木する感じのアプリケーション開発。 0. サンプルで作るモノ スライダーのUIで、Google Mapsのいわゆる、lat, lng, zoom の3パラメータを操作できるようにします。（Google Maps本体のナビゲーションで操作できることではあるんですが、そこは気にしない） Google Maps 本体 Latitude

Webフロントエンド・パフォーマンス 思考整理系。 Webフロントエンドにおける3要素として、過去のセッションでは下記の3つを中心に紹介していました。 通信コスト - Networking 描画コスト - Rendering 計算コスト - Computing これらの問題は複雑に絡み合い、時として相反する関係をとります。例えば、通信コストを減らすために、視覚表現を画像からCSS3に置き換えたら、描画コストが高くなってしまいスクロールが重くなった、なんてケースは頻繁にあるでしょう。 理解の問題 この3つのコストは確かにパフォーマンスに影響を与える要因であります。しかし、その要因がWebフロントエンドのページライフサイクルにおいて、どこで影響を与えているかは表してくれません。 要因がどのような影響を及ぼしうるかという基礎的な理解と、パフォーマンスの問題に取り組むための切り口としての理解は、そ

HTML5 Conference 2013 で、僭越ながら1セッション担当させていただきました！やっっったら、奥行きの深い部屋で、後ろのほうの方にはスライド見えづらかったかもしれません。ごめんなさい。部屋の奥行きのわりに、スクリーン小さいという不遇がありました orz ということで、スライドのURL共有とか、イベントの感想とかです。 Rendering Performance 動画 Webフロントエンドのパフォーマンスは、今やページの初期表示を早くすることだけではありません。昨今のHTML/CSS/JavaScriptを駆使したWebコンテンツを、スムーズに動かすには、ブラウザのレンダリング(描画)処理について知る必要があります。このセッションでは、レンダリング上のよくあるボトルネックの見つけ方と対処を中心に、最適化Tipsをお届けします。 ちと粗いのですが、今回の参考URLリストです。

普段気をつけてるよリスト "モバイルで、WebViewとブラウザのコンパチで、特にセオリー化されていないデザインモジュールのなか、装飾画像もふんだんに使うぞ系サービス開発" の文脈における、パフォーマンス確保のため気をつけてるよリスト。 よく、パフォーマンス「向上」とか「確保」とか申しますが、メンテナンスコストなどと天秤にかけて、「必要十分」のラインを狙うのが重要だと思う次第。 画像リソース 画像リソースを揃えるときのセオリ。圧縮率とか最適化とか細かいチューニングはあれど、大雑把に下記を守る。そしてImage Optim（or 相当の処理）。 JPEGはプログレッシブで画質60くらい（オレ目安） PNGは差し支えない範囲で色数をきちんと削る 50px未満のサムネイルは@2.0xなリソースにしない 案外、Androidあわせの@1.5xや@1.0xでも大丈夫なことすらある GIFアニメを入れ

またアニメーション... ボタンなどのUIにGPUアクセラレーションが効いたアニメーションをつけたとき、iOSにおいてはiPhone4か4SのWebViewあたり、Androidにおいては….まぁ機種依存的(げんなり)に、アニメーションの立ち上がりが遅いことがあります。 その辺を調査していたところ、position: relativeの指定による、意図しないレイヤー生成＆GPUアクセラレーション巻き込みによって、何かしら合成レイヤー周りでオーバーヘッドが発生してしまっているんではないかな、という憶測に行き着いた次第。今回はその辺りを見ていきます。 GPUアクセラレーションが効いたアニメーションは、CSS Animations、CSS Transitionsのほか、特殊なプロパティ（transform3d: scale(1,1)とか）で強制的にGPUアクセラレーションを効かせたCanvasア

安定したビルド環境 gruntの広まりを感じる...。みんな...package.jsonをつかうのです...そしてバージョンにも気を遣ってstableな環境を目指すのです....安定して使えないビルド環境はいくらナウくてもゴミです....。 — aho.mu (@ahomu) December 11, 2012 夏前に、nodeでビルドってなんかナウい(∩´∀｀)∩ワーイって使い始めて、秋から現職のプロジェクトで実践してみた結果、そんな当たり前な視点を忘れないようにしなければ、と強く思った次第。 今回は下記の2点を紹介します。 Gruntと永く付き合うためのノウハウとして、package.jsonを使った管理について 賞味期限の短いノウハウとして、Grunt 0.4.0への移行に関して Gruntイイヨーの続きとして、今後付き合っていくために必要なことを改めておさらい。 1. packa

Yeoman - Modern workflows for modern webapps Brunch | HTML5 application assembler 今回はニュートラルな気持ちで、並べて触ってみるのが目的なので、どっちが良い・悪い、という評価的な主張は重きを置いてない。（感想としては混じってるけど）淡々と記録しているだけなので、流し読んでいただければ幸い。 CompareTable Install Skeletons/BoilerPlate Scaffolding (generate/destroy) Build Server & Watch Test PackageManager Conclusion Compare Table とりあえず比較表。オリジナルから行列加えてる。 Original: Compare Table - Brunch | HTML5 applicat

昨今jQueryについての所感とつきあい方を考える はじめはPHPとa-blog cmsがメインだったこのブログも、いつの間にかJavaScript（jQuery）とご飯レシピブログという謎な方向への珍走を遂げています。 そんな中、個人的にjQueryとのつきあい方について色々聞いたり思ったりで、だらだらとアウトプットしてみます。オチはつきませんでした。ﾀﾞﾗｧ...('A`) ってこれ、今年の3月に大半書いていて、なぜか8月も末の今頃に加筆修正かけたので色々アレなところあったらごめんなさい！！！もったいないから公開させてください、、てへぺろ(・ω<) なぜjQueryなのか jQuery周辺のノリ（何でもjQuery・コスト感なくjQuery・jQueryスニペット信仰）などに、正直ネガティブな感情抱くこともありますが、素直な気持ちで見ればjQueryはとても効率的だと思います。Web上