これはRemix 3のソースリポジトリです。現在も活発に開発中です。

今年初めに、Remix 3に関する私たちの考えをまとめたブログ記事を公開しました。ウェブ開発の哲学と、なぜ今が新しいものを始めるタイミングだと考えているのかを説明しています。Remix 3の開発にあたり、私たちは以下の原則に従っています:

1. モデル優先の開発。AIはユーザー体験と開発者のワークフローの両方において、人間とコンピュータのインタラクションモデルを根本的に変革します。LLMのソースコード、ドキュメント、ツール、抽象化を最適化します。さらに、アプリケーション向けの抽象化も開発し、単なるツールとしてではなく、製品内でモデルを活用できるようにしましょう。
2. Web APIを基盤に構築する。スタック全体で抽象化を共有することで、人間と機械の両方でコンテキスト切り替えが大幅に減ります。Web APIとJavaScriptの基盤の上に構築しましょう。なぜなら、それが唯一のフルスタックエコシステムだからです。
3. 厳密に実行時間。バンドラー/コンパイラ/タイプ生成(および実行前の静的解析)を設計すると、API設計が不十分で、最終的にシステム全体が汚染されます。すべてのパッケージは静的解析を期待せずに設計されなければならず、すべてのテストはバンドルなしで実行されなければなりません。

Welcome to Remix 3!

This is the source repository for Remix 3. It is under active development.

We published a blog post earlier this year with some of our thoughts around Remix 3. It explains our philosophy for web development and why we think the time is right for something new. When working on Remix 3, we follow these principles:

1. Model-First Development. AI fundamentally shifts the human-computer interaction model for both user experience and developer workflows. Optimize the source code, documentation, tooling, and abstractions for LLMs. Additionally, develop abstractions for applications to use models in the product itself, not just as a tool to develop it.
2. Build on Web APIs. Sharing abstractions across the stack greatly reduces the amount of context switching, both for humans and machines. Build on the foundation of Web APIs and JavaScript because it is the only full stack ecosystem.
3. Religiously Runtime. Designing for bundlers/compilers/typegen (and any pre-runtime static analysis) leads to poor API design that eventually pollutes the entire system. All packages must be designed with no expectation of static analysis and all tests must run without bundling. Because browsers are involved, --import loaders for simple transformations like TypeScript and JSX are permissible.
4. Avoid Dependencies. Dependencies lock you into somebody else’s roadmap. Choose them wisely, wrap them completely, and expect to replace most of them with our own package eventually. The goal is zero.
5. Demand Composition. Abstractions should be single-purpose and replaceable. A composable abstraction is easy to add and remove from an existing program. Every package must be useful and documented independent of any other context. New features should first be attempted as a new package. If impossible, attempt to break up the existing package to make it more composable. However, tightly coupled modules that almost always change together in both directions should be moved to the same package.
6. Distribute Cohesively. Extremely composable ecosystems are difficult to learn and use. Remix will be distributed as a single remix package for both distribution and documentation.

Goals

Although we recommend the remix package for ease of use, all packages that make up Remix should be usable standalone as well. This forces us to consider package boundaries and helps us define public interfaces that are portable and interoperable.

Each package in Remix:

• Has a single responsibility