Zenn
Open3

Remix その 1：Remix に入門する

Remix
nukopynukopy

これ読む

  • 「Remix」という哲学を学ぼう──学習コストを最小限に抑えるReactベースの注目フレームワークを解説！

https://codezine.jp/article/detail/16642?p=3&anchor=0

参考

  • (2021/11, Zenn) Remix という 考え方

https://zenn.dev/kaa_a_zu/articles/fbd06ca2cc3b86

  • (2023/08/27, Zenn) Remix + Cloudflare Workers + D1 + KV + Queue + R2 + DO で簡単なアプリを作る

https://zenn.dev/razokulover/articles/144a98d27c658e

  • (2022/02, Zenn Scrap) Remix メモ
    • 時雨堂の人

https://zenn.dev/voluntas/scraps/dd25a40c433234

  • (2021/01/21, Zenn) 【Next.js】CSR, SSG, SSR, ISR があやふやな人へざっくり解説する

https://zenn.dev/akino/articles/78479998efef55

  • (2020/09, mizchi さん) Cloudflare Workers それは Frontend / Node.js が CDN Edge Side まで拡張されるもの

https://mizchi.dev/202009122126-cloudflare-workers

  • (2018/11, Publickey) VM よりコンテナよりもさらに軽量な分離技術、V8 の Isolate を用いてサーバレスコンピューティングを提供する Cloudflare Workers

https://www.publickey1.jp/blog/18/vmv8isolatecloudflareworkers.html

  • Cloud Computing without Containers

https://blog.cloudflare.com/cloud-computing-without-containers/

nukopynukopy

Remix Philosophy

https://remix.run/docs/en/1.19.3/pages/philosophy

Remix の背景

  • Remix 開発チームは様々な Web サイトの開発をしていた。静的なサイト、ソーシャルメディアプラットフォーム、学習管理プラットフォームなどなど。
  • Remix 開発チームは React Training という研修を行う企業を運営しており、何百もの開発チームの研修を行ってきた。これらの経験を元に Remix を開発した。
  • Remix では、Web プロジェクトにおけるフロントエンドとバックエンド両方の動的な性質（dynamic nature＝「流行り廃りが激しい」と理解）を扱うことができる。

We've worked on a lot of different types of websites: static sites for credit card companies, social media platforms, learning management systems, content management systems, and e-commerce to name a few. We've also trained hundreds of development teams with our training company, React Training. These teams build websites we all use regularly. Based on our personal development experience and our clients' products, we built Remix to be able to handle the dynamic nature of both the front end and the back end of a web project.

Remix の哲学

Remix の哲学は以下の 4 点に集約される：

  • サーバー / クライアントモデルを受け入れること。これにはソースコードとコンテンツ / データの分離を含む。
  • Web の基盤技術であるブラウザ、HTTP、HTML とともに、そしてそれらに逆らわずに動作すること。これらは常に良いものであり、過去数年間で非常に良くなってきた。
  • ブラウザの動作をエミュレートすることで、ユーザーエクスペリエンスをJavaScriptで拡張すること
  • 基盤技術を過度に抽象化しないこと

The Remix philosophy can be summed up in four points:

  • Embrace the server/client model, including separation of source code from content/data.
  • Work with, not against, the foundations of the web: Browsers, HTTP, and HTML. It’s always been good and it's gotten really good in the last few years.
    -Use JavaScript to augment the user experience by emulating browser behavior.
    -Don't over-abstract the underlying technologies

Server / Client Model

  • サーバサイドの速度の問題であれば自分で対応できるが、ユーザのネットワークを早くすることはできない（ユーザのネットワーク環境に左右されづらいデータフェッチの必要性への言及。Next.js の App Router とか RSC でもデータフェッチをサーバーサイドで行う試みが進んでいる。ユーザ環境のネットワーク速度はサービス提供側でコントロールできないため、初期表示のためのデータフェッチの責務をすべてクライアントサイドで担う構成にすると、パフォーマンスの問題が発生しやすい）
  • あなたができることは、ネットワーク経由でユーザに送信するデータ量を減らすことだけだ。JavaScript、CSS、JSON をより小さくしろ。
  • Remix はこれをサポートする

With today's web infrastructure you don't need static files to make your server fast.

この文章よく分からなかったけど、こういうことらしい↓
SSG はないってことかな。

SSRをリクエストの都度実行するとWebサーバーが詰まってしまうので、静的なファイルの割合が多いほど高速化できる、というのはWebサイト構築の定石のひとつでしたが、近年ではそれ以外のアプローチも現実的になってきました。 https://remix.runのWebサイトでは、エッジコンピューティングによる分散システムを構築することで、リクエストの都度SSRを行ってもパフォーマンス上の問題は起こりづらくなっているようです。

引用元：https://codezine.jp/article/detail/16642?p=3&anchor=0

Web Standards, HTTP, and HTML

  • Web 標準、HTTP、HTML といった技術は長い間存在しており、信頼性がある。Remix はこれらを完全に受け入れている。
  • Remix は API を最小限に保つように努めており、その代わりに Web 標準の API を使用して動作する。
    • fetch API など
  • Remix を習得するに連れて Web 標準を習得できる。
  • ブラウザがユースケースの API を既に持っている場合、Remix はそれを使用する。

Progressive Enhancement

  • ref: MDN Web Docs 用語集：Progressive Enhancement（プログレッシブ・エンハンスメント）

https://developer.mozilla.org/ja/docs/Glossary/Progressive_Enhancement

  • プログレッシブエンハンスメントのポイント
    • サービスを不可欠なコンテンツと機能のベースラインの提供のための設計思想
    • ユーザの環境に応じて使い勝手を進化させる設計思想
  • Remix はブラウザで JavaScript が有効であるか否かに関係なく機能する（→ベースラインの提供）
  • JavaScript が有効な環境では UX をより良くできる（→使い勝手を進化させる）
    • ページ遷移の高速化、より良い UI など
  • ポイントは、アプリを JavaScript なしで動作させることではなく、より単純なクライアント / サーバーモデルを保持すること。JavaScriptを排除できるというのは、良い副次的効果である。

Don't Over Abstract 過度な抽象化をするな

  • できる限り Remixisms を避ける（Remix らしい設計とか Remix らしい書き方みたいな「Remix らしい〇〇」を避ける）。その代わり、既存の Web 標準 API を使いやすいようにしている（Web 標準 API の便利ラッパー的な）。
  • Build Better Websites, Sometimes with Remix：Remix の立ち位置は「より良いウェブサイトを構築する。時々 Remix を使って。」という立ち位置。Remix を中心に据えるというよりも、Remix があれば便利だよねくらいな立ち位置。
  • Remixを上手に使えるようになると、一般的な Web 開発も上手くなる
  • Remix の API は、基本的なブラウザ、HTTP、JavaScriptの使用を便利にするが、これらの技術はユーザに隠蔽されていない
    • 例えば、アプリの特定のレイアウトに CSS を適用するためには、HTMLの <link> タグの値を持つオブジェクトの配列を返す、ルートモジュールメソッドの links を使用する。アプリのパフォーマンスを最適化するためには十分な抽象化を行うが、基盤となる技術を隠すことはない。Remix での links を使用したアセットのプリフェッチの方法を学ぶことで、任意のウェブサイトでのアセットのプリフェッチの方法も学ぶことができる。
  • Remix が上手く扱えるようになると、Web もうまく扱えるようになる。

Get good at Remix, get good at the web.

所感

できる限り Web 標準の API を使って Web サイトを実装しましょう。その手助けをするよ、という感じのフレームワークだね。とにかく使ってみないと分からんね。