You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
サーバーサイドレンダリング、Isomorphic、Universal JavaScriptなどの言葉をよく見かけます。なるほどね、良さそうだね、外部公開するサービスを書くことがあったら挑戦してみたいね、Mithrilにもisomorphic-mithrilってのをがんばっている人がいるし、みたいなことを漠然と思っていたのですが、最近ASCII.jpのシステムコールプログラミングの連載を書いていて、あらためてHTTPの仕様を見返してみて、逆にサーバーサイドレンダリングをしない方がいいのではないか、と思い始めました。 追記(23:30): サーバーサイドレンダリングと書いていますがUniversal JavaScriptみたいな凝ったビューの更新の意味です。 サーバーサイドレンダリングの欠点 サーバーサイドレンダリングのメリットとしてあげられるのは次の2点です。 検索エンジンのクローラー向け
サーバサイドレンダリング、してますか? ~ 憧れのIsomorphic JavaScript ~ Meguro.es #6 2016/10/13 http://meguroes.connpass.com/event/39081/
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 今回のエントリでは、 Angular2 とServer Side Rendering(以下SSR)について書きたいと思います。 Angular2でSSRを実現するためのモジュール群は angular-universal で開発されています1。 コーディングレベルでのモジュール利用方法についても記載しますが、APIや利用可能なオプション等の詳細については日々刻々変化が予想されます。 今日時点では、Angular2の開発チームが目指しているゴールと、それを支えているアーキテクチャについて理解しておいた方が今後の変化に柔軟に対応でき
現状どんな実装があるかはここみてください Isomorphic JavaScript - The future of web app development 主張 Node.jsは現状フロントエンドユーティリティに最も適している Node.jsは一般にサーバーサイドでの運用は難しいし、自分もそう思う どうせやるなら、Node.jsにしかできないことをやるべきだ Node.jsのキラーアプリはRailsクローンではなく単体ソースからクライアント・サーバーのコードを同時に生成するIsomorphicフレームワークであるべきだ。 これだけは他のフレームワークには絶対に真似できないので、一応可能性は検証すべきだ 自分で実装することで、MeteorとかDerbyはなぜうまくいってないのかも考えたい というわけで Isomorphicなフレームワークを自分で作ってみたいと思っていた。 今ならせめてCo
nodejs.connpass.com ニフティの場所難易度高い&都庁前駅でGoogleマップ使ったら現在地が御徒町になるなどのトラブルがあり、最初の発表の半分くらいを聞き逃したorz 感想 真のIsomorphic(Truly Isomorphic)ってのがよくわかってなかったが、「IsomorphicってServer Side Renderingのことっしょ?」に対する「いやいや、Viewだけじゃなくて全部が両方で動くことやで」みたいな理解であっていますでしょうか? 「Server SideレンダリングできるとSEOにいい」とか個別の事象に対して注目してしまっているので、 新しい技術や流行りの技術が出てきたことによってArchitectureがどう変化したかや、 それらが生まれる背景にある課題など、 もっと俯瞰して見る必要があるなと感じた。 @koichikさんの歴史から辿っていく感じ
PART1はこちら : 【翻訳】2015年に向けたJavaScriptアプリケーションアーキテクチャ PART 1 オフラインの課題 オフラインでアプリケーションを使えなければ、真のモバイルWebエクスペリエンスとは言えません。 これまで、アプリケーションをオフラインで使用することは根本的に困難でしたが、状況は改善されつつあります。2014年を振り返ると、WebプラットフォームのAPIは、より良いプリミティブを提供できるよう進化し続けてきました。最近の事例で最も興味深かったのは Service Worker です。Service Workerは、オフラインでもサイトを稼動させることができるAPIです。ネットワークリクエストに割り込んで、そのリクエストをどう処理すべきかをブラウザに伝えます。 コントロールのレベルが適正かどうかという点以外は、アプリケーションキャッシュのあるべき姿を実現してい
Last week we were working on making our website indexable for search engines. This is the story of rewriting it and the summary of what we have learnt. Background Two months ago when we created RisingStack we had to decide what kind of technologies we wanted to use on our website. We only had a few static pages with some event tracking. So it was very simple, but we wanted to keep it scalable and
By Spike Brehm This post has been cross-posted on VentureBeat. At Airbnb, we’ve learned a lot over the past few years while building rich web experiences. We dove into the single-page app world in 2011 with our mobile web site, and have since launched Wish Lists and our newly-redesigned search page, among others. Each of these is a large JavaScript app, meaning that the bulk of the code runs in th
最近、新しいプロジェクトをやろうと思う度に使う言語で悩んでいます。好きなのはRubyまたはnodeなのですが、テンプレートエンジンやWebブラウザで使う言語を統一したいと思うとnodeが最適に思えます。 しかしそんな中、Rubyでもサーバサイドとクライアントサイドを統一できるフレームワークが出てきました。それがVoltです。 Voltの使い方 VoltはOpalを使うことでクライアントとサーバのコードを一緒に書くことができます。以下はデモのTodoアプリ。 サーバサイドに遷移することなく描画が更新されます。WebSocketを使っています。 二画面にした場合にも同時に反映されます。 VoltはHerokuにデプロイすることもできます。YouTubeの動画を見ると分かりますが、まるで魔法のようにサーバ向けに書いたRubyのコードがそのまま使えたりと、サーバとクライアントの区別がなくどんどん開
Need help deciding which isomorphic JavaScript framework to use? Here’s a quick look at popular frameworks, including React, Derby, Meteor, and Rendr. React isomorphic JavaScript framework One of the most widely used frameworks today is called React. Facebook is the company that developed React, which could prove to be beneficial. Because Facebook is used by so many people across the world, the fr
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く