Purpose and reasons
앞으로 전개할 내용을 요약하면, ‘굳이 타입스크립트를 써야할까?’ 를 주제로 삼고, 그와 관련된 내 생각과 그 생각의 토대를 써나가려한다. 나는 타입스크립트를 반대하지 않는다. 회사에서 사용한다면 사용하지만 개인 프로젝트에는 쓰고 싶지 않다는 생각이다. 마치 대한민국 국민의 남자라면 특별한 이유가 없다면 군대를 가지만, 안갈 수 있다면 그냥 안간다다. 비유가 조금 이상한데, 아무튼 나는 군대도 다녀오지 않았다. 🤨
굳이 하지도 않아도 될 입장을 공개적으로 글로 말하려는것에 대해 고민이 많았다. 그러나 이 글로 자바스크립트와 타입스크립트의 알지 못했던 또 다른 정보 정도로만 봐줘도 좋겠다. 틀린 정보가 있다면, 댓글은 사용하지 않으니 jsveron23@gmail.com 로 알려주시면 정정하겠다.
History
자바스크립트의 기본 역사와 사실을 참고하려면, The Past Present and Future of JavaScript 으로 가면 된다. 여기서는 내가 바라본 흐름을 말하고 싶다.
자바스크립트는 기본적으로 애플리케이션을 바탕으로 사용된 언어가 아니었다고 생각한다. 그렇게 사용이 가능해도, 대부분 브라우저에서 간단한 이벤트를 처리하는 정도로 사용했다. 그러다 나중에 여러 기술들이 나오면서 프레임워크도 등장하는데, 그러다보니 나중에 애플리케이션을 구현할 정도의 레벨의 언어가 되었고, 지금은 프론트엔드 개발의 중심으로 자리잡고 있다.
당연히 한명이 감당할 수 있던 수준에서 이제는 여러명이 같이 개발을 필수적으로 하는 단계가 되었고, 나중에는 결과적으로 타입스크립트가 주는 장점이 있었고, 그래서 개발자들이 선택하고 있다고 본다. 그러나 나는 반대로 타입스크립트 없이도, 그 장점들이 대부분 가능하고 생각한다. 왜냐면 나는 타입 자체는 프로그래밍의 패러다임과 경험으로도 제한이 가능하다고 보기 때문이다.
그리고 그런 대체 가능한 부분을 앞으로 다른 내용과 같이 소개하려 한다.
Reason 1 - Performance
첫번째 이유는 성능상으로 큰 이점을 주지 못했기 때문이라 느꼈기 때문이다. 이를 처음으로 ‘타입스크립트를 왜 써야할까?’ 라는 생각이 싹트게 된다. 물론 성능으로만 타입스크립트를 논할 수 없다. 아무튼 JIT 를 똑같이 거치기에 타입을 정한다는게 무슨 소용일까 해서 고민을 했었다. 다시말해 우리가 말하는 타입스크립트의 과정을 전부 끝내면, 나중에 설명할 렉서 단계 부터 다시 시작하는 것이다. 그러니 브라우저에 도달하면, 크게 여파가 없게 된다.
나는 보통 FP 패러다임을 적용하고 인자를 타입이 있다는 가정으로 만든다. 왜냐면 타입을 중구난방으로 쓰면, 함수를 순수하게 만들기 쉽지 않기 때문에 FP 를 쓰면 자연히 함수를 만들 때 타입을 고려하고 처음부터 만든다. 그리고 성능으로만 타입스크립트를 원한다면, 성능이 필요한 부분은 WASM 을 추천하고 싶다. 그리고 이 글을 추천한다.
TypeScript is statically typed. It means that we define types for our variables and we need to stick to them later on – it defines boundaries of some kind. In a way, it is similar to other statically typed languages, like C# or Java. It differs greatly, though – the information about types is used only during the process of transpiling our code to plain old JavaScript. It means losing all the information about types in the end – we do not get any optimization from it. Libraries that I want to show you today introduce new types of variables and are a little bit similar to truly statically typed languages.
앞의 성능의 이유는 간단한 절차를 설명하면 내가 왜 그런 생각을 처음에 했는지 이해가 쉽다.
우선 첫번째로 우리가 생각하는 자바스크립트 코드는 Lexer(이하 렉서) 의 단계를 거친다. Monaco Editor 를 전에 잠시 보면서 ‘이 에디터는 어떻게 자동완성을 할까?’ 에 대한 궁금증이 잠시 있었고 그래서 그 와중에 Benjamin Yang 전 대표님을 통해 렉서의 존재를 알았다. 그 때는 머리가 아파서 그저 참고만 했었다. 아무튼 파서의 전 단계로 보면 된다. 즉, 자바스크립트에서 렉서를 통해 토큰으로 분리하고 나면, 파서를 통해 AST 로 만들게 된다. 다시 말해 렉서를 통해 자바스크립트 Syntax 가 토큰으로 분류되고 파서를 통해 AST 로 만들어진다.
이 두 단계를 거치면 그 다음은 바이트 코드로 바꾸는 작업을 한다. 그리고 그 다음 인터프리터 단계로 들어간다. 그 다음 자바스크립트를 하다보면 누구나 접하는 JIT 단계로 들어간다. 그리고 런타임 단계로 가는데, JIT 은 그냥 실시간 컴파일러이기 때문에, 이를 최적화 하는 단계에도 돌입하고 또 다시 런타임 단계를 반복한다.
물론 자바스크립트의 구조를 이해 하지 않고 타입을 무조건 동적으로 만드는 개발자가 있다면 타입스크립트 사용을 권장하고 성능에 이점을 줄 수 있다고 보나, Senior 를 넘어가는 개발자라면 성능이나 최적화는 많이 알고 계시기 때문에 극도로 성능을 원하는 부분은 WASM 을 적용해도 되지 않을까 한다.
아무튼 이런 생각이 싹트게 되는 계기일 뿐 모든 이유는 아니다. 이번 글은 마무리 하고 다음 글로 다른 이유도 정리하려고 한다. 나는 장문을 잘 못쓰겠다.