SPA + サーバーサイドレンダリング、そのダルさに関する私見
いわゆる SPA + サーバーサイドレンダリングがダルい 唐突ですがおさらいです。 なぜサーバーサイドレンダリング（SSR）が嬉しいかと言えば 初期表示の Critical Rendering Path を短縮できる SEO における保守信仰にやさしい（） 古いブラウザ・低性能マシンにやさしい yahoo/fluxible による SPA + Server Rendering の概観 ::ハブろぐ であり、特に SPA + SSR の文脈においては Universal Architecture による SPA + SSR は、技術的には過渡期の歪なキメラっぽさが拭いきれませんが、昨今の Web フロントエンドにしては珍しくビジネス的な説得力があります。 SSR なのでSNSや検索からの流入による初期表示が速い SPA なので回遊時のページ遷移も速い SSR なので古いブラウザでも CSS
2014年のWebパフォーマンスふりかえり - 来年以降の期待etc
ひさびさにWebフロントエンドパフォーマンス系の話題をつらつらと書いてみます。例によってモバイル系開発者寄りの視点かもしれません。文中の参照リンク多め。 ファクタ まずはパフォーマンスに影響を与えるファクタについての所感。Webパフォーマンスにおけるイニシャライズとランタイム ::ハブろぐ で示した分類に基づきます。 イニシャライズ（いわゆるページロード） 4GやLTEが普及してもコンテンツの肥大化には追いついていない concat と CSS Sprites の呪いが解けない HTTP/2 の Streams and Multiplexing に期待 HTTP/2 の Server Push にも期待 画像周りだと <picture> 関連仕様も使いたい（srcsetだけならいける？） WebRTC とか WebSocket とかストリーミングとかは？ （やや疎い、てかイニシャライズじゃ
Front-end with Node.js - Node学園祭 2014
Node学園祭・初参加 初参加だったんですが、ビギナー＆フロントエンド向けのNode.jsツール系セッションを担当させていただきました。なんかめっちゃ緊張した･･･。 参考リンク集 1. Package manager npm Bower npm とフロントエンドのパッケージ管理の未来 ::ハブろぐ The npm Blog — npm and front-end packaging Npm Tips · fiveisprime npmのあまり知られてない機能 10選 - from scratch npm-shrinkwrap Bower Resolutions - Jake Trent 2. Task runner Grunt: The JavaScript Task Runner gulp.js - the streaming build system Node.js の Stream
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 に代表されるクラスベースのオブジェクト指向モデルに多少の制約が必要に
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
Componentによるフロントエンドのパッケージ管理
直近で、新規案件に関わることになりそうなので、ライブラリ選定やタスクランナー、そして今回の依存管理のようにベーシックな話が続いてます。次第に、具体的な実装やコード設計のポストが多くなる･･･はず。 今回はVue.jsでも触れましたが、改めてcomponent - modular javascript frameworkについて。 概要 Componentはパッケージマネージャー兼、依存解決込みのビルドツールです。クライアントサイドについて、JSのパッケージマネージャーやビルダーは既にありますが、Componentは HTML/CSS/JSをセットにして扱うことができます。 npmでいうpackage.jsonと同様に、component.jsonという定義ファイルによって、パッケージの依存関係やリポジトリなどの各種情報を示します。 component/component コア部分のリポジト
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
