Isomorphic Javascriptのジレンマ - TanUkkiiのブログ

@axrossがIsomorphic Javascriptを実現すべく、社内にNode.jsを啓蒙する発表の場に僕はいた。僕は２ヶ月前までWebフロントエンドエンジニアであり、今はサーバーサイドエンジニアをやっている。その２つの立場から@axrossの発表を聞いて、自分の考えを書いておく。 社内事情的な側面もあるので、この記事を読んでからの方が理解しやすいと思います。 フロントエンド側の動機 僕もIsomorphic Javascriptの未来を見たい。@axrossが社内でこのようなきっかけをつくってくれたのは嬉しい。これを機にフロントエンドとサーバーサイドが歩み寄るといい。 サーバーとAPIとの統合時に、型の違いなどの衝突が起こることがある。レスポンスのJSONの中で、数値であるべき値が文字列であったり、もっと酷いと空の配列がnullになっていたりする。PHPの連想配列やSQLドライバ

[teppeis]

目的と手段が逆転してるような

[k12u]

“ネイティブ側でレスポンスの形式が正しいかどうかテストを書いている人”そんなことをするならそのテストを仕様としてサーバでCIさせるべき。組織としてムチャクチャ。

[ledsun]

“Isomorphic Javascript”に期待しすぎ？アプリケーションコードでサーバとフロントで共有できる部分は小さそう。/同じライブラリを使えるのは嬉しい。サーバとフロントで担当者が分かれているなら関係ないかも？