はじめに 新年早々に面白そうな記事を見つけました。ReactでのAPI呼出しを最適化するために「部分的にサーバサイドで実行するコンポーネントを作る」というもののようです。 あるいは去年の記事ですが気になってたものとしてBlitz.jsでReactベースのFWであるnext.jsに永続化層を持たせてRailsのようなFWにしようというアプローチもあります。 どちらの記事も書かれてる内容自体は分かる気がするものの 「それをフロントエンドでやる意味あるの？」 というのが拭えずイマイチ腑に落ちなかったんですが、単純に 「私と最前線でやられてる方々で期待してるものがたぶん違う」 という気がしてきたので、その辺を整理のために書いてみます。 注意書き Vue.js/Nuxt.jsは少し触ったことがありますが、React Server ComponentsやBlitz.jsを触ったことは無いです 「なんで
Isomorphic ES Modules Earlier I demonstrated how to build a Single Page App which shares templates with the Server Side Code. (See the video below.) We share the web app’s templates to enable the first page load to be pre-rendered on the server. This practice lets Web Apps start faster and be more resilient to network failure. In the live coding session we use the new EcmaScript (ES) Modules becau
アイソモーフィックJavaScript 作者: Jason Strimpel,Maxime Najim,牧野聡出版社/メーカー: オライリージャパン発売日: 2017/07/04メディア: 単行本（ソフトカバー）この商品を含むブログを見る アイソモーフィックJavaScript(Isomorphic JavaScript)とは、クライアントとサーバで同じJSコードを共有して実行できるようにしようという概念。*1 この本ではリクエスト/レスポンスの古典的なWebアプリケーションから始まって、AJAX・SPAそしてIsomorphicとWebアプリケーションアーキテクチャの歴史を追って説明してくれている。それも単に歴史を辿るのではなく、当時なにが問題とされて、それをどう解決しようとしたかという背景がわかりやすく解説されているのが特に良かった。 ただ最後の方でReactやAngularJS、An
Contractor roles While our Careers site currently focuses on direct employment roles with Pinterest, we also offer temporary (contractor) assignments through our trusted third-party staffing firms. Job postings for contractor assignments on some of the most popular professional networking sites and job boards will clearly indicate the assignment duration, the staffing firm that will be the direct
みなさんこんにちは、サイバーエージェントでフロントエンドを中心に開発しています原(@herablog)です。 アメブロでは、2016年9月にフロントエンドをJavaベースのアプリから、node.js・Reactベースのアプリへとシステムの移行をおこないました。本記事では、その移行へといたる経緯やゴール、システム設計、その結果についてお伝えします。 リリース直後に気づいているツワモノな方もいらっしゃいました。 アメブロのSP版がReactのSSRでフルリニューアルしたのを観測した — hr (@hrloca) 2016年9月1日 システム移行へといたる経緯 2004年から始まり、日本国内で最大規模のブログサービスとなったアメブロは、システムの肥大化や多数の関係者が存在したことによるモジュール・導線の急増などの理由により、ページ表示スピードが遅くなり、ページビュー数にも明らかに影響を与えるよう
A recent trend in the web development world is to use JavaScript on the server to assemble pages there, with the same code that is used to manage them in the client. That lets you initially see content faster, especially on mobile devices and helps with search engines. How are we supposed to call code that runs on either server or client? Michael Jackson doesn’t like a recent proposal: So Charlie
Isomorphic あらため Universal ？ 一時期火がついていた Isomorphic について。各自がプロダクションの事例を作り上げる潜伏期に入ったのか、はたまた本当に一過性で火が消えたのか、コモディティ化を遂げたのか分かりませんが、あまり耳にすることがなくなった印象です。 そんな中ですが先日、Universal JavaScript — Medium が公開され、なるほど Universal ってキモチになったので、タイトルに反して以下は Universal と呼称します。 今回の話題にするのは module レベルではなく Universal な JavaScript architecture のほうです。アーキテクチャのレベルで Universal なコードが役立つ代表的ケースは SPA (Single Page Application) と SSR (Server S
Rubyベースの文法でJavaScriptにコンパイルされるAltJS-Opal言語とReactiveなWAF Voltの情報まとめです。 2015/06/30 時点の内容をまとめました。 Official Site Opal Official Docs Opal Docs GitHub Opal - GitHub Playground 環境構築せずにPlaygroundで試せます。 Playground - Opal Volt - Web Application Framework Links Volt Framework Official Volt Framework - GitHub Volt Docs(English, Japanese 選択可能) What is Volt? Qiita Opal Ruby で JavaScript を書く、 Opal を使ってみる 最近のOpal
This summer, JavaScript Scene conducted a JavaScript tech survey via social media over the course of a few days. Just under 800 people participated. Respondents are all engaged in JavaScript discussions on social media including Twitter, Facebook, and Google+. Most of the respondents came from Twitter. As promised, here are the results: React is RisingAlmost half (45%) currently use Angular, and m
Universal (aka "isomorphic") means that it's designed to run a lot of the same code on both the client and the server. Typically that includes a lot of rendering and domain logic. There are many advantages to building apps this way, but the primary advantages are: Cross-functional teams. Since everything is written in JavaScript, it's easier to build teams who know how to work on both the client a
In the beginning, there was Netscape. And Netscape wanted to run Scheme in Netscape Navigator. So they hired Brendan Eich to work on it. But then they changed their minds and decided they wanted Java instead. And lo, JavaScript was born. And it was good (enough). Some years later, Ryan Dahl had this crazy idea to pair Google’s V8 JavaScript runtime with libev so developers would have a way to run
ここ最近のフロントエンドに対しては、 流れが速すぎてついていけない あるライブラリを使おうと思ったら今はみんな別のライブラリを使ってると言われてもう何を使えばいいかわからない ビルドするのが当たり前になっていて、HTML/CSS/JavaScriptを少し修正したいだけなのにどうすればいいのかわからない importやclassなど自分の知っているJavaScriptでない せっかく覚えても半年後には使えない知識になっている という意見を聞きます。果たしてそうでしょうか？ そこで本トークでは、サーバーサイドをメインで書いている人に向けてフロントエンドの今をいくつかのトピックに分けて解説します。 例外もありますが、新しいライブラリは突然何の脈絡もなく登場したわけではなくそれまでの流れを踏まえて登場しています。 本トークでは、個々のライブラリの使い方紹介ではなく、その背景や目的などに注目するこ
Single Page Application + Server Rendering yahoo/fluxible を使って、Single Page Application と Server Rendering の良いとこ取りのアーキテクチャを目指す。ある程度の複雑性と引き換えに、双方の利点で双方の欠点を打ち消し合うことができるため、全体的には良好なユーザーインタラクションを期待できる構成。 なぜ Single Page Application なのか 画面遷移時するたびにJavaScript/CSS のパースと評価をしなくて良くなる 画面遷移時のトランジションを柔軟に適用できる 画面遷移をまたがった実装が可能になる（あくまで可能になるだけ） なぜ Server Rendering するのか 初期表示の Critical Rendering Path を短縮できる SEO における保守信仰
architectural overview of a working isomorphic solution plus some funny images of course
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
