SPA + サーバーサイドレンダリング、そのダルさに関する私見
いわゆる SPA + サーバーサイドレンダリングがダルい 唐突ですがおさらいです。 なぜサーバーサイドレンダリング（SSR）が嬉しいかと言えば 初期表示の Critical Rendering Path を短縮できる SEO における保守信仰にやさしい（） 古いブラウザ・低性能マシンにやさしい yahoo/fluxible による SPA + Server Rendering の概観 ::ハブろぐ であり、特に SPA + SSR の文脈においては Universal Architecture による SPA + SSR は、技術的には過渡期の歪なキメラっぽさが拭いきれませんが、昨今の Web フロントエンドにしては珍しくビジネス的な説得力があります。 SSR なのでSNSや検索からの流入による初期表示が速い SPA なので回遊時のページ遷移も速い SSR なので古いブラウザでも CSS
React に対する感情とかコンポーネント管理ライブラリの選定とか
コンポーネント管理できそうなライブラリの選定 ここでいうコンポーネントは HTML 要素をコンポーネントに見立てるような、近代 Web フロントエンドにおける狭義のコンポーネントです。大まかな条件は次の3点。 コンポーネント中心の開発ができること >= IE9 をサポートすること（切っても良さそうなんだけど...） 既製品・スクラッチは問わないが極端なリスクは踏めない（納期がシビア） あとは期待度や API のセンスなど、個人的な審美眼判定に依ります。 angular/angular : 2.0 が正式リリースしたらまた会いましょう jashkenas/backbone : 最近のコンポーネント管理には及ばない Custom Elements ( Polymer ) : polyfill が >= IE10サポート segmentio/deku : 振る舞いは十分だったけど、>= IE10
Google I/O で v1.0 が発表された Polymer の Elements Catalog が面白い
Polymer Elements のカタログページ Site: Polymer Element Catalog Repo: Polymer/polymer-element-catalog Polymer は、これからの Web 標準の一角を占めるであろう Web Components のラッパーライブラリです。その Polymer で作られたコンポーネントのカタログサイトが公開されていました。 これまでも Core Elements や Paper Elements が Polymer のコンポーネントとして提供されていましたが、分類も新たにレパートリーが拡充されています。 Cart に入れて Download カタログには各コンポーネントのドキュメントやデモが載っていて、使いたいものをチェックして Cart に入れていきます。必要なコンポーネントを Cart に入れてダウンロードさせると
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 における保守信仰
Web Components における依存ライブラリの断片化とエコシステムのコロニー化
あくまで可能性のはなし あまりポジティブな意味で捉えられないのでタイトルですが、あくまで可能性の話であり、直面するかもしれない問題についての一次考察って感じです。 コンポーネントが依存するライブラリの断片化 ラッパーライブラリによるロックインまたは断絶 その他の妄想 ここでは上記の3点について、つらつら書いてます。 1. コンポーネントが依存するライブラリの断片化 これまで開発者は自身がすべてのコンポーネントを管理するつもりで、ときにミニマルに、ときに富豪的に、依存するライブラリを選定していました。 いつの日か Web Components を前提にしてコンポーネントを選定するときも、個々が依存しているライブラリまでコントロールしきれるかは定かではありません。 依存関係の肥大化は避けたい 例えば npm であればさほど気にならない依存関係の肥大化も、ブラウザで実行されるコンポーネントの場合
Polymer v0.8.0 Preview 所感
Improvement Polymer の Twitter アカウントが気になる発言をしていたので、Polymer のアップデート内容を確認した。 Next major version of Polymer: 5 x faster in Chrome, 8 x faster in Safari. Up to 87% smaller (15KB, 6KB gzipped) pic.twitter.com/SBJhuxIxXd — Polymer (@polymer) November 19, 2014 Chrome と Safari における実行速度の高速化はもちろんわかるが、ファイルサイズが 87% 減というのはかなり大きい。v0.5.1 の polymer.min.js が 123KB なのに対して、新しい v0.8.0 では 15KB になっているということだ。 それなりに大きい取捨選
AngularJS についての所感
AgularJS に対する気持ち 所感といいつつ、主に自分がつらさとして感じていることを書く。所感シリーズとしては jQueryについての所感 も併せて読みたい。 この学習曲線の中でいうと、たぶん今の自分は Very Cool! の頂点から降りている最中くらいだと思う。そして、マサカリをふりかぶった諸兄にひとつだけ言いたいのは、共感脳を養った方がモテるということだ。 チキンハート的弁解: 以下はAngularJSに関するつらさを述べることに専念するために、美点を挙げていないだけであってAngularJSを全方位的に貶めたり、何かと比べて明確にクソだというような意図はない。 画像は AngularJS: The Best Parts · Anand Mani Sankar からの引用。X軸にある www.bennadel.com は AngularJS 大好きさん。 辛1. $scope が
続・PhantomJSで遊ぶヽ|・∀・|ノ Static HTMLの生成
Ajaxページの問題と、StaticなHTMLの生成 Ajaxでズンドコやってるページだと、検索エンジンからのアクセス時に空ページでSEOがアウアウァ！！って話はよく耳にします。 GooglebotがAjax的なアレコレについて賢くなってきているとは申します。AJAX クロール: ウェブマスターおよびデベロッパー向けガイドのような情報ドも公開されているので、それに従えばきっと....という所ではありますが、より確実にStaticなHTMLを！という声も少なくありません。 ということで、今回は、AjaxでDynamicなページを元に、StaticなHTMLを自動生成しておいて、検索クローラからのアクセスにはStatic HTMLを返却する、ということを考えてみます。ここではStatic HTMLの生成まで試していて、URL設計とかサーバサイドのアレは割愛。Phantomしたいだけなので。 サ
AngularJSとサーバーサイドテンプレートの混在とngNonBindable
Angularとサーバーサイドテンプレートの混在 先日リリースされた某サービス(他社)がAngularを使っていて、XSSがボロボロ出てくるだとか、{{var}} な形式で値を入力するとng-template側でテンプレーティングされるだとかの話がありました。 詳しくは見ていないので、今回の話とまったく同じかは把握していませんが、サーバーサイドテンプレートを混在させると、次のようなことが起こりえます。 例えばejsとAngular サンプルとしてスカスカなControllerを用意します。 angular.module('app', []).controller('AcmeCtrl', function($scope) { $scope.foo = 'bar'; }); ejsは次のようなテンプレートになっているとします。
`that = this` について思ったこと
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(
HTML5では、data-* の書式でカスタム属性 ( Custom Data Attribute )を定義できるらしい ハブろぐ - havelog.ayumusato.com
Tweetボタンのdata-urlとかdata-text属性はアリなのか？ 結論は、本エントリーのタイトルの通りHTML5の仕様の中では定義済みということでアリでした。エントリーの下の方で情報の出所を紹介してます。以下は、後半まで逐次的な調べ物メモです。 以前、公式Tweet Buttonを早速試した！で、Tweetボタンを紹介しましたが、そのときから気になっていた素朴なギモン。 HTMLの属性って、勝手に拡張していいの？ Tweetボタンの場合、data-url, data-via, data-text, data-related, data-count のようにHTMLでは未定義（と言っていいのか分かりませんが）の、属性をベタベタ貼って動作させています。 確かに、こうやってJS等で利用する情報を好きに定義して良いなら、かなりラクチンな訳ですが、これはHTML的にはやっても良いの？？とい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
