サーバーサイドレンダリング不要論 - Qiita
サーバーサイドレンダリング、Isomorphic、Universal JavaScriptなどの言葉をよく見かけます。なるほどね、良さそうだね、外部公開するサービスを書くことがあったら挑戦してみたいね、Mithrilにもisomorphic-mithrilってのをがんばっている人がいるし、みたいなことを漠然と思っていたのですが、最近ASCII.jpのシステムコールプログラミングの連載を書いていて、あらためてHTTPの仕様を見返してみて、逆にサーバーサイドレンダリングをしない方がいいのではないか、と思い始めました。 追記(23:30): サーバーサイドレンダリングと書いていますがUniversal JavaScriptみたいな凝ったビューの更新の意味です。 サーバーサイドレンダリングの欠点 サーバーサイドレンダリングのメリットとしてあげられるのは次の2点です。 検索エンジンのクローラー向け
GoでたたくTCPソケット（後編）
ソケットの使い方そのものはシンプルです。 繋いでしまったら、書き出し、読み込み、クローズしかありません。 APIリファレンスを読めれば、とりあえず使うことはできるでしょう。 ですが、ソケットまわりのパフォーマンスはユーザの体感に直結します。通信が切れる、タイムアウトなどのエラーが発生する可能性も多々あります。 最大の効率を得るには、ボトルネックを中心に最適化を行うしかありません（これは『ザ・ゴール』というビジネス書で「制約理論」として示されている問題でもあります）。 今回は、前回に引き続き、HTTPの機能を再現しながらソケットの使い方について学んでいきます。 HTTPの歴史を通して、ソケットの実行効率を向上させる方法を具体的に見ていきましょう。 圧縮 HTTPの速度アップ手法としてよく使われているのが圧縮です。 昔よりもインターネットやWifiの性能は向上しましたが、それでもCPUを使って
やっぱりサーバーサイドレンダリングなんかしなくていいやという気持ち - console.lealog();
個人の意見 aka ポエムです。 界隈的には今さら感がすごいけど。 そんな今さらポエった事情としては、 とある案件でSPAをReactで作りつつサーバーサイドレンダリング（以下SSR）をすることになるかも SPAじゃないページもまとめてReactでSSRすることになるかも ただ個人的にはSPA+SSR不要論者 サーバーサイドのテンプレートとしてのReactも冗長なだけやろ派 でも仕事なのでしゃーない（お客様がそう申されるなら・・ なのでやるからには再考察してみて、前向きにやれる要素を見つけたい！ けどどんだけ考えてもやっぱり意義が見つけられなーい( ´Д｀)=3 という感じで、SSR自体の是非はまあどうでもよくて、ただ個人的に「しなくていい」と思ってる気持ちをまとめたものです。 技術に是も非もないです。大事なのはどう使うかなのです。 ちなみにやってみた結果・・とかいう話ではなく、やってない
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
