웹 프론트엔드 ReScript 실무 사용에 대한 간단한 메모

ReScript를 아마 실무에서 1년이상 써본 사람은 많지는 않을 것 같은데 (굳이 그 대상을 한국으로 한정짓지 않아도), 사실 제대로 된 블로그 글을 쓸만한 여유는 없고 그 경험을 메모처럼 적어본다.

ReScript에 관심이 있지만 실무에 도입할 만한지 고민하는 사람들이 있을 것이라고 생각한다. 특히 TypeScript 대비 큰 장점이 있는지, 도입에 문제가 될만한 부분이 있는지 궁금해할 것 같다. 입지가 잘 다져지지 않은 언어를 영업을 해야 하는 입장에선 보통 좋은 부분만 말할 수 밖에 없기도 하고, 실무로 사용해본 사람이 많지 않아 실무 도입의 단점이 잘 정리되어 있는 경우는 흔치 않을 것 같다. 그래서 간단하게 정리해 본다.

ReScript 실무 도입의 장점

• TypeScript에 익숙한 사람이면 상당히 금방 배울 수 있다. 적절한 가이드만 있다면.

• 언어에 킬러 피쳐들이 많다. 패턴 매칭, Optional, if as expression, pipe, etc... 추론도 매우 강력해서 타입을 반복적으로 손으로 써줄 일이 거의 없다. 오히려 TypeScript 대비 초심자에게 더 적합.

• 생각보다 active하게 개발되고 있다. 개발진들이 (내 기준) 이슈에 매우 민첩하게 대응해주는 편이다. 커뮤니티도 어느정도 형성되어 있다.

ReScript 실무 도입 시 단점

• 당연하지만, 익숙해지는 데 시간이 좀 걸린다. 숙련된 개발자도 보통 적응기간이 1-2개월 정도 걸리는 것 같다. (함수형 언어에 대한 선행학습이 되어 있을 경우, 더 빨리 안착할 수 있다)

• 당장 가져다 쓸 수 있는 바인딩이 잘 없다. 바인딩을 직접 쓰는 데 많이 익숙해져야 한다.

  • 대부분 바인딩은 굉장히 간단하지만, 일부 라이브러리들은 사고방식의 변화를 요구하기도 한다. (react-hook-form을 ReScript로 어떻게 바인딩할 것인가?)

  • (경우가 흔하진 않지만) 빌드툴이 타입을 emit해야 하는 경우 좀 더 스코프가 커질 수도: rescript-relay

• 돈의 맛이 느껴지는 TypeScript 개발 도구들을 쓰다 ReScript 세계로 오면 조금 부족함을 느낄 수 있다. 대부분의 경우는 괜찮지만, 시도때도 없이 나는 알 수 없는 VS Code 익스텐션 에러 등에 조금 지칠 수도

bonus: ReScript Gotchas

• 파일명의 제약이 있다.

  • Next.js 사용 시 file-based routing 이슈가 자연히 발생하는데, route를 위한 파일은 TypeScript로 작성하고 ReScript 파일명은 자유롭게 작성하여 export ... from ... 으로 가져오길 추천한다.

• React 바인딩 / DOM API 등의 지원이 TypeScript 대비 불완전하다.

  • 1-2개의 props만 다른 비슷한 React 컴포넌트에 대해 모든 prop들을 따로 타이핑을 해야 할 수도 있다.

  • DOM API가 typesafe하지 않은 이유를 찾아봤다: 글 링크

  • JSX 타입체크가 불완전하다. svg attribute prop을 넣어봤을 때의 비교: TS ReScript

• ReScript를 쓴다고 자동으로 type-safe 해지는 것은 아니다.

  • 당연한 이야기지만, 바인딩이 잘못되면 런타임 에러가 얼마든지 발생할 수 있다.

  • %identity 같은 escape hatch가 존재하기에, 함수 구현을 어느정도 신경써야 한다. (참고)

• 함수는 기본적으로 currying이 되어있다.

  • 함수를 일부만 apply해서 원하지 않는 결과를 얻는 실수를 할 수 있다.

더불어

• ReScript의 발전을 위해서 사내용 코드가 일부 가려진 실무 사용 사례 미러가 공개되어 있으니 관심이 있으면 참고해봐도 좋을 듯하다.

• 실무 도입에 관심이 있다면, Reason Seoul 커뮤니티 디스코드에서 많은 도움을 받을 수 있다.

• 이 글은 완전히 검증된 내용이 아니기에 참고만 바라며, 글 내용의 수정이나 보완 의견은 댓글로 부탁 드립니다.