Medium - 7 really good reasons not to use TypeScript
in Trend
Trend 파악을 위한 Medium 기고문 포스팅 - 타입스크립트를 지양해야 할 7가지 타당한 이유
모든 사람들은 타입스크립트를 사랑합니다. 자바스크립트가 가지고 있는 많은 문제를 해결해주고 JS의 슈퍼셋이며 여러분의 코드의 에러를 찾아주고 가독성을 높여줍니다. 타입스크립트를 사용해야 할 이유는 매우 많지만 여기서는 사용하지 않아도 되는 7가지 타당한 이유를 제시해 보겠습니다.
It is risky
흠, 타입스크립트가 컴파일타임에 타입 정의와 체크를 추가하는 것 뿐인데 어떻게 위험할 수 있을까요? IDE 개발툴 처럼 모든 타입 불일치를 경고해 줄까요? 정확히 그런 것들 때문에 위험한 것입니다. 타입스크립트는 컴파일 시점에서 ㅏ입을 체크하며 이용 가능한 타입만 확인합니다. 네트워크 호출이나 시스템 라이브러리, 플랫폼 특화 API나 정의되지 않은 외부 라이브러리 타입들은 타입스크립트에서 체크할 수 없죠. 타입을 체크하는 데 익숙하시고 플랫폼의 코드에 대한 완벽한 이해가 없다면 에러와 버그들은 여전히 나타날 것입니다.
자바스크립트에서는 타입을 예측할 수 없기 때문에 여러분이 원하는 값인지 확실히 하려면 변수의 값을 체크해야 합니다. 만약 특정 상황에서 값을 확인할 필요가 없다면 안 할 수도 있죠. 타입스크립트에서는 여러분이 컴파일러에게 타입체크를 맡겨버리기 때문에 항상 체크를 할 것입니다. 두가지 방법을 모두 조합할 수 있겠지만 그러면 뭐가 좋은 거죠? 정의를 하는데 시간을 보내고 이런 정의가 런타임에 제대로 되는지 확인하는 코드를 작성하면 처음에 타입체크는 사실상 무의미 하게 됩니다.
It is messy
또 다른 모순도 있습니다. 언어가 가독성과 명확함을 코드에서 담아내려면 모호할 수 밖에 없습니다. 무슨말인지 오픈 소스 라이브러리 예를 통해 말씀드리겠습니다.
//TODO: do this more elegantly
;((currentReducer as unknown) as Reducer<
newState,
newActions
>) = nextReducer
이것은 Redux 라이브러리에 나오는 것으로 이 4줄의 코드는 nextReducer를 currentReducer에 할당하는 것입니다.
// HACK: Since TypeScript inherits static properties too, we have to
// fight against TypeScript here so Subject can have a different static create signature
/**
* Creates a new cold Observable by calling the Observable constructor
* @static true
* @owner Observable
* @method create
* @param {Function} subscribe? the subscriber function to be passed to the Observable constructor
* @return {Observable} a new cold observable
* @nocollapse
* @deprecated use new Observable() instead
*/
static create: Function = <T>(subscribe?: (subscriber: Subscriber<T>) => TeardownLogic) => {
return new Observable<T>(subscribe);
}
다음 예제는 RxJS 라이브러리에 나오는 것입니다. 만약 제가 도움을 얻으려는 툴과 고군분투 해야한다면 저는 그게 좋은 툴이라고 생각하지 않습니다.
It does not solve the problem
타입스크립트는 자바스크립트의 문제를 해결해 준다고 하지만 전혀 아닙니다. 동적 타입은 자바스크립트의 문제가 된적이 한번도 없습니다. 정말로 문제가 되는 것은 NaN === NaN이 false가 되는 점, 세미콜론이 있어도 개행을 하는 것이 객체의 스코프를 바꾸는 것, OOP의 syntactic sugar가 발생하는 것입니다. 그리고 타입 스크립트는 이런 것을 전혀 해결해 주지 않고 JS 커뮤니티에서 찾아보라고 할 뿐입니다.
JS에서 타입을 정의하지 않는 것이 문제가 된다고 하더라도 TS가 이것을 해결해 주지 않습니다. 이런걸 해결해주는 것은 Java, C, C#과 같은 사전 컴파일 언어입니다. 이런 것들이 컴파일 과정에서 강력하게 타입을 체킹하고 실행됩니다. 인터프리트 언어로는 가능하지 않죠.
It is not a superset, it is a subset
타입스크립트는 뭔가를 자바스크립트로 만드는 것입니다. 자신들이 소개하는 것처럼 절대 모집단이 될 수 없습니다. 여러분이 자바스크립트로 하려는 것을 제한하며 강력한 부분 사용하지 못하게 되는 것이죠. 정말 좋은 개발자가 되고 싶다면 컴포팅해주는 것에 안주하지 마시고 자바스크립트의 유연성과 강력한 힘을 이해하려고 하셔야 합니다.
It is open-source, but nothing more
타입스크립트가 오픈소스라서 사용한다고 하는 분들도 많습니다. TS 컴파일러는 MIT 라이센스로 되어있죠, 사실입니다. 그러나 여전히 거대 기업인 마이크로소프트의 지배하에 놓여져 있고 오픈소스라는 점은 그냥 마케팅용일 뿐입니다. 오픈소스를 민주주의와 혼동해서는 안됩니다. 마이크로소프트는 무료로 여러분들이 TS로 하려는 것을 만들어줄 것입니다. 여러분은 그냥 지켜보기만 하면되죠. 반면에 JS는 국제적인 위원회에 의해 돌아가며 커뮤니티의 승인이 없으면 어떤 것도 변경하지 못합니다.
But big companies use it…
큰 기업들이 이것을 사용한다는 것이 이유라는 것도 웃긴거 같습니다. 큰 기업들은 오래된 코드도 쓰고 세금을 안내려고 사기도 치고 여성들을 차별하기도 합니다. 근데 타입스크립트를 사용하는 것이 갑자기 좋은 이유가 되나요??
But it has more features…
더 이상은 아닙니다. TS가 2012년에 나왔을 때는 클래스와 같이 JS에서 지원하지 않는 기능들이 있었지만 시간이 지난 후에는 TS가 JS의 기능을 따라오려고 고군분투 하고 있습니다. 만약 JS의 기능 중 빠진 것이 있다면 babel 플러그인이 알아서 처리해 줄 것입니다.
Summary
- 타입스크립트의 단점; 어차피 값을 확실히 알기 위해선 체크를 해야한다. 사전 체크는 큰 의미가 없다
- 왜냐하면 타입스크립트에 정의되지 않은 타입들은 체크가 되지 않기 때문이다.
- 특히나 타입스크립트가 모든 타입 오류를 해결해 줄거라고 믿는 것도 위험하다.
- 타입체크는 사전컴파일 언어가 아니면 완벽히 해결할 수 없다.
- 타입스크립트가 처음에는 많은 기능을 가지고 있었지만 (2012) 지금은 아니다.
- JS의 많은 기능을 제한한다. 얻는 장점은 적은데 비해 JS의 유연성과 많은 것을 포기해야 한다.
