# TIL: esbuild의 처리 방식


`swc`의 변수 처리 패스를 병렬화하려고 고민하다가, `esbuild`에 좋은 구현체가 있을 것 같아서 그걸 참고하려고 소스코드를 봤다.

근데 보다보니까 뭔가 모듈 개수가 너무 적었다. 그리고 transform에 관련된 것처럼 보이는 모듈이 하나도 없었다.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1713874200751/2fe810d5-54d9-4888-80a2-7a26e1943cdc.png align="center")

`swc` 모듈은 이렇게 많은데 말이다.

그래서 대충 훑어보니 `JsFeature`이라는 타입이 있었다. 그 타입으로 검색하면 관련 모듈들이 나올테니 그걸로 검색해봤는데, 역시 transform에 관련된 모듈이 없었다. 그러면 파서나 렉서에서 처리한다는 것일거고, 마침 검색 결과에 파서도 있길래 봤다.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1713874205469/7fc89180-f35f-4ac5-b7a2-5256d292dbf5.png align="center")

보니까 파서에서 최신 문법을 처리하고 있었다. 솔직히 이걸 보고 좀 실망했다. 실망한 이유는 최근에 내가 러스트의 가성비가 안좋다는 생각을 하고있었기 때문인데, 구체적으로 말하자면

> 제약에 비하면 최적화가 잘 안되는 것 아닌가

> go로 `swc`를 짰으면 훨씬 더 빠르지 않았을까

이런 생각들이었다. 두번째는 `&mut` 두 개 못 만드는 제약이 너무 빡세서 러스트로 짜다보면 병렬화가 제한받는 경우가 많은데 그런 경우에 차라리 다른 언어로 병렬 처리를 하는 게 낫지 않았을까하는 소리다.

근데 절대 아니라는 걸 깨달았고, 그게 실망한 이유이다.

`swc`나 타입스크립트 타입 체커는 '러스트라서' 구현하기 어려웠다. 그래서 좀 쉬운 go 같은 언어로 다시 짜는 게 낫지 않을까하는 일말의 희망? 같은 게 있었다. 그런데 절대 아니다. 내 성격에 제너릭도 없는 언어에서 `esbuild`처럼 파서에서 신규 문법을 처리하진 않았을 것이고, 당연히 지금보다 훨씬 느렸을 것이다.