前置き この記事は Frontrend Advent Calendar 2013 の7日目です。 意見表明を避けてたジャンルだけど、俺流Backbone.jsとの付き合い方と、それを反映したライブラリについて書いてみる。大半が夏前に書かれていたけど、イマイチで放置してた系を掘り起こした！ 職場近くに俺流塩らーめんというお店があって、そこの熟成塩ラーメン(¥680)が、スガキヤのラーメン(¥280)に近い味してる気がする。¥400余分に払っても価値がある。 巷ではdata bindingsだとかMV*の在り方に関心が集まっている昨今、マイペースにAOP風（記述言語がないので実装はmixin...）とか、Viewの領域管理の表現に腐心していた。 今の時点ではこれがベストとは思っておらず、つまるところ Marionette.js あたりを上手に使うことに注力すれば良さそうというのが結論だ。そこに

Vue.js 軽量でパワフルなデータバインディングMVVM, vue.jsで遊んでみた - mizchi's blog を読んで触発されたので、自分も外見的に良いなと思ったポイントだけ書き留めてみます。さすがに実戦投入できていないので、そのあたりの精度は悪しからず。 サンプルコードの雰囲気 サンプルコードとか自分でちょっと触ってみたときの感触からは、以下のポイントが気に入りました。data-bidingsとかは前提として便利です。はい。 覚え切れそうな分量のAPI Class: Vue - vue.js 脳みそちっちゃいので助かります。それに尽きる。 プロパティによる宣言っぽさ Angularだとイベントハンドラ類を書くにも、$scopeに都度ハンドラを仕込んでいくのがあまり好きでないです。工夫で回避できそうですが、与えられたスタートが下記のような状態であることには変わりません。 angu

思いつき だいぶ前からGrunt周りというかGruntそのものへの関心が薄れゆくなか、タスク周りがやたらと充実してきたエコシステムの恩恵を、ただただ享受するにとどまっている。 業務で700行のGruntfile.jsを見かけて、SAN値をもっていかれた折に前々から感じていた疑念が表に出た。 「これ、Gruntに仕事させすぎじゃないの」 分担してもよいのでは 前述の700行のなかには、ファイルのビルドをはじめとして、ユニットテスト、E2Eテスト、ドキュメント生成、ローカルサーバー、LiveReload etc etc etc ...すべてひとつのファイルに入っていた。 (; ⁰⊖⁰) Oh... いまいち感覚的なトコロなので表現しづらいのだが、役割としてあまりにGruntfileで表現している内容がごった煮すぎるように思う。 自分の場合、テスト周りはtestemにしていて、ドキュメント生成系

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アニメを入れ

thatに思いを馳せる JavaScriptにおいて that = this とか self = this なパターンを頻繁に使うと、作業者の理性が保証されない場合に下記に示す2点の問題が起こりう得ると思っている。 「あー、どうなのかなー、うーん」と思いながら書いてみる。 1.メソッド分割が適切におこなわれない雰囲気 ちょっと極端かも知れないが、Backboneっぽいコードを例にしてみる。 initialize: function() { var that = this; this.listenTo(this.entity, 'success', function() { var bar = that.foo(); that.$el.find('.qux').text(bar); // long. // long.. // logic... }); this.entity.execute(

どうやら周囲のフロントエンダは、WebPagetestくらい自前でホスティングして、ゴリゴリ解析しながら日々の改善に役立てているらしいので僕もマネしてみました。jsPerfを自分専用の環境にクローンしてみると同系統の続編です。 WebPagetestはいわゆるウェブサイトのパフォーマンス計測ツールです。こんな感じで細かく計測してくれて、ボトルネックの調査などに役立ちます。WebPagetest Documentationを見ると、色々と興味深いAPIや開発中のAgentも控えているようですが、まずは環境を用意するところまで。 ただのインストールログです。 要件 Private Instances - WebPagetest Documentationを参考にセットアップを進めていきます。必要なのはPHPとApacheが走るWebサーバーと、テストAgentとして走るWindowsマシンです

表題の件について情報を漁った 現時点で裏取り検証をまったくしていないので、議論対象の参考程度でお願いします。 これから実際に手元のプロダクトで検証していく予定ですが、誤読や内容などの疑わしきはTwitterとかでマサカリ投げてください。 ここでは海外のイカしたgeekらが調べてくれた、貴重な情報を信じて話を進めて参ります。素直が一番って、ばーちゃんが言ってました。 Browser Cache キャッシュと言っても無限の領域ではなく、むしろ現実的に出回っているモバイルデバイスのリソースは、ごくごく有限です。その上でブラウザの振る舞いを理解できていないことを反省して、ちょっと調べてみた次第。 まずはブラウザキャッシュに依存したストラテジを支える、キャッシュコントロール + ユーザー操作に関するブラウザの基本的な振る舞いについて。 Early findings: Mobile browser c

スライド 振り返り 50分という限られた時間の中で、Network・Render・Computeという3本柱についてご紹介するという構成に挑ませていただきました。 恐らくフロントエンドが専門でない方も多くいらした中で、どこまでニュアンスだけでも届けられるように、という面の調整が多かったです。 結果的には目に見えるRenderについて多めに盛り込んで着地しています。 WebKit依存の内容が多めの所から、Canaryに載っている開発者ツールの使い方を通して、パフォーマンス問題の検証と対策について肉付けしている構成です。 参考にした資料のURLリスト 導入のあたり 開発者のための WebKit (“WebKit for Developers” 日本語訳) Performance Checklist for the Mobile Web - YouTube Strangeloop - Impac

JavaScriptの暗部を感じるカオス JavaScriptのライブラリを読み解いていると，「お前は何を言っているんだ状態」に陥ることがよくあります．難解なコードを通り越して黒魔術になるとついていけません…． そんなコードリーディングをする中で，初見では意味が分からなかったり，分かりづらかったりした記法をまとめてみます．コードリーディングの一助になりますれば幸い． eachな感じのループ×2 比較的簡単な類ですが，定石パターンなので一応．色々あると思いますが，自分がよく使う2パターンだけ紹介します． var elms = [1, 2, 3], e, i = 0, while (e = elms[i++]) { // おぅふ // i -> 1 } 単純に配列から1個ずつ取り出すだけなら上記のような感じです． var elms = [1, 2, 3], e, i = 0, iz = elm

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

Fxck iOS6!!! と思っている方々も少なからずいらっしゃるのではないでしょうか。ぼくは今わりとそう思っています。 だって、Androidでposition: fixedとか、z-indexとか、怪しげなモノって使わずに避ける、慎重に触れるとかまだ何とかなるじゃないですか。伝家の宝刀「Androidですから…」って言い訳も少なからず使えますし。けれども、AjaxとかTimer周りって、必須すぎて避けようがないんですよ。任意のタイミングで再描画起こすためにsetTimeoutとか使いますよね。遅延描画的な溜め込みとか、ほら、いろいろ。しかもそれ、iOSの最新版ですよ。 そんなわけで、ぼくはiOS6があまり好きではありません。（前置き） でまぁ、Ajaxについては下記によくまとまっていますし、9月ごろの情報ですね。 Understanding the iOS6 AJAX bugs | G

Backbone.js Advent Calendar 2012の21日目でございます。おもむろに小ネタなパターンを、3つほど簡単に紹介してみる次第。 renderとpresenterの分離パターン これは Backbone.js Tips and Tricks を参考にしています。実践してみたところ、なにかと具合が良くてお気に入りのパターンです。 Backbone.View.extend({ tmpl: 'path/to/tmpl', initialize: function() { this.model = new SomeModel(); this.model.fetch({ success: this.render }); }, presenter: function() { var data = this.model.toJSON(); // data manipulation

前段 Backbone.js (Sub)View Rendering Trick | Joe Zim's JavaScript Blog Rendering Views in Backbone.js Isn't Always Simple by Ian Storm Taylor Break Apart Your Backbone.js Render Methods by Ian Storm Taylor 海外のイケメンたちが書いた記事からくみ取ったパターンを、ひっじょーに薄めて紹介します。SubViewの中身までは及ばず、単純にMainViewが所有する要素の中で、SubViewをrenderするときの簡単な定義について。 MainViewの中にSubViewを設ける MainView（ページ全体を司るView）の中に、SubView（部分的なView）を埋め込むときのパターンについて。よ

CreateJSのコードを組み込んでみた 前提、ともかく現在の仕事においてアニメーションの導入という要件が出てきて、JavaScript書いてる者としてどのように解決しようかと相談した結果、下記の状況・前提からFlashのToolkit for CreateJSを利用することに決めた次第。 自分でアニメーションの動きを作ったことない アニメーターな方がFlasher 取り急ぎカッコ良く動いて欲しい が、今後を考えるとCSSでFlashの動きから書き起こすのダルい という理由から下記のソリューションを導入する方向になりました。（今の時点で本当にデプロイまで至れるかは、まだ手探りなので参考までに） CreateJS | A suite of Javascript libraries and tools designed for working with HTML5 Flash to HTML5

当日のスライドでございます。 先月のはじめごろにイベント告知 Frontrend Vol.4で宣伝させていただいたイベントが先々週末に無事おわりました。席数に対して、非常に多数の（300/200人!!）お申し込みをいただきありがたい限りです。 Frontrend Vol.4 powered by CyberAgent, Inc. セッション概要・スライド・デモなどは、↑のサイトにまとまっています。t32k++ 60分そこそこのプレゼンだけで、正確な情報が伝わる/伝えられるとはあんまり思っていないので、ワークショップ系でもない限り「興味の喚起と独学の助け」をモットーにやっております。そのようなご託を含め、今回は先月のCSS Nite LP26でStylus推ししたときとは、また趣の違うふっかけ気味な構成でございました。 動画とデモファイル jQuery to Backbone from Fr

何かと不透明なあたり 気がつけば一ヶ月ほどブログを更新していませんでした。リハビリ記事です。 今回は、GPUを効かせる == それに関連するプロパティ（ただしOSやバージョンによって何がトリガかは厳密に異なる）を適用したら挙動が改善した、というようなノリの体験TIPSをゆるくまとめました。 このあたりの振る舞いについては、描画パフォーマンスの問題として、それなりに明らかになってきているように思います。WebKitのレンダリングプロセスにはじまり、GPU命令のサポートが受けられるのはどんな操作だとか、GPUへ処理が預けられるレイヤーの生成がどーとか、最近よく見聞きします。 自分が業務で扱っているスマートフォン向けのWebサービスでは、このような描画パフォーマンスの問題は、スクロールパフォーマンスと合わせて非常にクリティカルです。この辺りについてのロジカルなまとめは、某氏が近日中にまとめるらし

設定が肥大化したときにミスりやすい WebStormぐらい賢いエディタ（IDE）を使っているときはよいのですが、簡素なエディタでちょいちょい編集したいときなどに、しょーじき、カンマとか波括弧（brace）の閉じを誤ることがあります。 Adding preliminary CoffeeScript support. This is for issue #124. · 2f1cd72 · cowboy/grunt This should properly search for: grunt.js or grunt.coffee grunt file in current or parent directories tasks written as .js or .coffee files init templates written as .js or .coffee files そこでcow