여기는 Remix 3의 소스 저장소입니다. 현재 활발히 개발 중입니다.

올해 초 우리는 Remix 3에 대한 우리의 생각을 담은 블로그 글을 게시했습니다. 이 글은 웹 개발에 대한 우리의 철학과 왜 지금이 새로운 것을 할 적기라고 생각하는지 설명합니다. Remix 3 작업을 할 때 우리는 다음과 같은 원칙을 따릅니다:

1. 모델 우선 개발. AI는 사용자 경험과 개발자 워크플로우 모두에서 인간-컴퓨터 상호작용 모델을 근본적으로 변화시킵니다. LLM의 소스 코드, 문서, 도구 및 추상화를 최적화하세요. 또한, 단순히 개발 도구로서가 아니라 제품 자체에서 모델을 활용할 수 있도록 애플리케이션용 추상화를 개발하세요.
2. 웹 API 위에 구축하세요. 스택 전반에 걸쳐 추상화를 공유하면 인간과 기계 모두에서 컨텍스트 전환이 크게 줄어듭니다. 웹 API와 자바스크립트의 기반 위에 구축하세요. 이는 유일한 풀스택 생태계이기 때문입니다.
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