누가 깃허브 디스커션으로 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.

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