SPA + サーバーサイドレンダリング、そのダルさに関する私見
いわゆる SPA + サーバーサイドレンダリングがダルい 唐突ですがおさらいです。 なぜサーバーサイドレンダリング（SSR）が嬉しいかと言えば 初期表示の Critical Rendering Path を短縮できる SEO における保守信仰にやさしい（） 古いブラウザ・低性能マシンにやさしい yahoo/fluxible による SPA + Server Rendering の概観 ::ハブろぐ であり、特に SPA + SSR の文脈においては Universal Architecture による SPA + SSR は、技術的には過渡期の歪なキメラっぽさが拭いきれませんが、昨今の Web フロントエンドにしては珍しくビジネス的な説得力があります。 SSR なのでSNSや検索からの流入による初期表示が速い SPA なので回遊時のページ遷移も速い SSR なので古いブラウザでも CSS
Web サイトっぽい SPA に必要なブラウザナビゲーションのエミュレートなど
Web サイトっぽい SPA に立ち向かう 大分前の話ですが、Node学園 20時限目 今回もdots!!!!! - connpass で Client Side of なんちゃらfresh.tv としてお話した内容のうち、Web サイトっぽい SPA に関してだけこだわりを再抽出して書き留めます。 本件は、ページ全体のスクロールや頻繁なナビゲーションを伴わず、1画面におさまるレスポンシブな Web アプリを作っている場合はあんまり関係がありません。画面内の局所的な状態更新は、コンポーネントの責務分割やら何やらの設計なので実は別の話です。 総じて、Web サイトっぽいくせに大人の事情で Web ブラウザのネイティブなナビゲーションを積極的に破壊しにいくときの心構えです。 URL が変わっても最低限レンダリングできるまで画面更新を遅延させる 画面遷移に必要なのは、 URL が更新されても次の
リモートワークの勘所と限界について1年くらいの感想、組織にとっての選択肢作りの話
1年くらいリモートワークを続けてみた感想 まず当然ながら「リモートワークは生産性が高い！これこそ未来のワークスタイル！」のような感想はありません。 生産性やコミュニケーションに関連するメリット、デメリットをうまく相殺しきれれば、生活の自由度だけ向上してハッピー、と考えています。 今は自宅かレンタルオフィスのいずれかを作業場として開発などを行いつつ、本社がある渋谷には1泊2日の出張を月2回するようなペースで仕事をしています。基本は Slack でテキストチャットによるコミュニケーションをメインとしつつ、必要があれば MTG に Hangout でビデオチャットで参加します。 生産性は大して上がらない 期待していた生産性は、それほど向上することはありませんでした。 東京にさえいなければ気軽に MTG に呼び出されることもありませんし、開発に充てることが可能な時間は若干増えています。通勤時間が長
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 アプリケーション開発屋さんなので、Web サイト制作屋さんとはかなり文脈ズレると思います。 jQuery ファミリー 個人的には jQuery って、協業用のツールという位置づけでした。jQuery でさえ書かれていれば、jQuery 書ける人材のほうが外からも調達しやすいため、人員の流動にも有効と考えられる頃が確かにありました。 DOM に触れてくれるな勢の台頭 ところが昨今では AngularJS や React、その他ライブラリでも DOM 操作が大いに抽象化されていることが多く、jQuery で直接 DOM を操作すること自体が相性良くないケースが散見されます。今思えば Backbone.js くらいのころが jQuery 需要の最終ピークだったように思います。 jQuery プラグイン の需要減 jQu
ES6 の Project Skeleton (6to5 + browserify + power-assert) を作ってみた
かめ板 es6-Kameita ahomu/es6-Kameita es6-Kameita は ECMAScript 6 で JavaScript ライブラリを開発するためのプロジェクトスケルトン（テンプレート）です。初期設定はブラウザ向けですが、Nodeモジュールにも対応します。 6to5 でトランスパイルされたコードを Browserify でビルドし、mocha + power-assert でテストを実行します。Browserify を採用しているため、初期状態では bower に依存せず npm を活かしています。 経緯 6to5/6to5 がリリースされて以来、しばらく手元で ES6 を使い続けていたので、ぼちぼち開発の構成を固めてしまいたいなと思った次第。 最初は GianlucaGuarini/es6-project-starter-kit を fork して何とかしようと
npm とフロントエンドのパッケージ管理の未来
JavaScript 系パッケージマネージャの重複問題 npm は言わずもがな Node.js のパッケージマネージャだが、フロントエンド開発においては Bower も利用するのが一般的になっている。この現状の問題点は、package.jon と bower.json という似たような管理ファイルを二重で管理しなければならないということだ。 現状の使い分けをおさらいをしておくと、次のような感じになる。 タスクランナー（Grunt/gulp）・モジュールシステム（browserify/webpack）・テストスイート（karma/testem）などの開発環境系の管理が npm の主なお仕事。インストールされたパッケージは node_modules 内に展開されて、CommonJS スタイルのモジュール管理から利用する。 本題につながる話としては、ブラウザで動くライブラリの一部は npm にも
AngularJS についての所感
AgularJS に対する気持ち 所感といいつつ、主に自分がつらさとして感じていることを書く。所感シリーズとしては jQueryについての所感 も併せて読みたい。 この学習曲線の中でいうと、たぶん今の自分は Very Cool! の頂点から降りている最中くらいだと思う。そして、マサカリをふりかぶった諸兄にひとつだけ言いたいのは、共感脳を養った方がモテるということだ。 チキンハート的弁解: 以下はAngularJSに関するつらさを述べることに専念するために、美点を挙げていないだけであってAngularJSを全方位的に貶めたり、何かと比べて明確にクソだというような意図はない。 画像は AngularJS: The Best Parts · Anand Mani Sankar からの引用。X軸にある www.bennadel.com は AngularJS 大好きさん。 辛1. $scope が
Docker を Mac で使ってみた（Nodeアプリ例）
色々あってDockerした。さっくりとアプリ作るならHerokuも便利なのだけど、Dockerをサポートする他のPaaSも使えた方が便利そうな風潮を感じたので。 1. インストール＆導入 Mac OS X - Docker Documentation Releases · boot2docker/osx-installer からpkgインストーラをダウンロードして実行。適当にはいる。 boot2docker Mac OS X上で、Dockerを走らせるためのLinuxなVMを boot2docker で立ち上げられる。（boot2docker/boot2docker はpkgインストーラに含まれている） boot2docker init boot2docker up boot2docker init で初期化 boot2docker up で起動。dockerコマンドにホストを教えるための
Angularそっちのけで、Vue.jsについて所感
Vue.js 軽量でパワフルなデータバインディングMVVM, vue.jsで遊んでみた - mizchi's blog を読んで触発されたので、自分も外見的に良いなと思ったポイントだけ書き留めてみます。さすがに実戦投入できていないので、そのあたりの精度は悪しからず。 サンプルコードの雰囲気 サンプルコードとか自分でちょっと触ってみたときの感触からは、以下のポイントが気に入りました。data-bidingsとかは前提として便利です。はい。 覚え切れそうな分量のAPI Class: Vue - vue.js 脳みそちっちゃいので助かります。それに尽きる。 プロパティによる宣言っぽさ Angularだとイベントハンドラ類を書くにも、$scopeに都度ハンドラを仕込んでいくのがあまり好きでないです。工夫で回避できそうですが、与えられたスタートが下記のような状態であることには変わりません。 angu
`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(
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
