# swc 설계 철학



누가 깃허브 디스커션으로 swc의 html 모듈이 general purpose인지와 설계 철학이 무엇인지 물어봤는데, 답변한 김에 블로그에도 정리해두기로 했다.

https://github.com/swc-project/swc/discussions/7695

이는 html 모듈에만 적용되는 게 아니고, swc 전체에 적용되는 설계 철학이다.
내가 중요시하는 건 순서대로

1. 정확성 (표준 준수)
2. 빠른 스펙 업데이트
3. 범용성
4. 쉬운 사용성

이디.
순서대로 설명하겠다.

## 설계 철학

### 1. 정확성

swc는 컴파일러고, 나는 모든 컴파일러는 표준을 최우선으로 따라야한다고 생각한다.

그래서 bun을 굉장히 싫어한다.
원래 좋은 시도라고 보고 있었는데, 표준화 과정을 거치지 않고 jsx 문법을 건드려서 극혐하게 됐다.

### 2. 빠른 스펙 업데이트

swc는 차세대 문법을 바로 사용할 수 있게 해주는 게 목적인 프로젝트이다.
그런만큼 스펙이 업데이트 되었을 때 바로바로 반영하는 게 중요하다고 생각한다.
물론 자원이 그리 풍부하지 않기에 한계가 있지만 말이다.

### 3. 범용성

swc의 모든 AST 정의는 범용이다.
swc 프로젝트만을 위한 필드가 단 하나도 없다.
나도 swc를 다 직접 구현하기 전에 적당히 라이브러리 써서 날로 먹고 싶었는데, 범용 라이브러리가 하나도 없어서 결국 다 새로 구현해야했다.
남들은 같은 고생 안 했으면 좋겠어서 swc는 범용 라이브러리로 만들었다.

`esbuild` 같은 경우 파서에서 최신 문법을 옛날 문법으로 바꿔버리고, 타입스크립트 타입을 날린다.
그렇게 구현하면 매우 빠르다는 건 나도 안다.
근데 그래버리면 트랜스파일링을 사용할 수 있는 시점이 제한되고, 타입스크립트 타입 정보를 가져올 방법이 없다.
그래서 성능을 어느 정도 포기했다.

### 4. 쉬운 사용성

지나치게 쉬운 API는 성능 저하를 가져온다.
하지만 나는 `CowRcStr` 같은 걸 원하지 않았다.
러스트는 충분히 어려운 언어고 swc는 처음부터 범용 러스트 라이브러리로 설계되었기에 API 난이도 역시 고려사항이었다.
그래서 swc의 AST에는 라이프타임이 없다.
당연히 성능은 좀 떨어지지만, 라이프타임이 들어가기 시작하면 모듈로 가져가서 쓰기 훨씬 어려웠을 것이다.

## P.S.

의외로 성능은 설계할 때 그다지 중요시하지 않았다.
솔직히 러스트로 짜면 그냥 빠르다.
구현이 더럽게 어려워서 문제일 뿐이다.