Typescript, why? - Part 1 의 다음 글이다. 다시 언급하지만 나는 타입스크립트를 반대하는 사람이 아니고, 타입스크립트를 사용하지 않고도 순수 자바스크립트로도 장점을 찾을 수 있다에 가까운 사람이다.
이번에는 구글에서 타입스크립트 장점 의 키워드로 검색해서 나온 몇개의 글들을 토대로 글을 이어가려고 한다. 이 방법을 택한 이유는 각 장점이 소프트웨어 공학적인 관점보다는 Trend 를 따르려 하는 시도와 내가 생각하면 다르게 접근해도 되는 것을 이를 타입스크립트의 장점이라 서술하는 글들이 몇 있기 때문이다.
Reason 2 - Pro?
TypeScript를 사용하는 가장 큰 이유 중 하나는 정적 타입을 지원한다는 것이다.
정적타입은 내가 볼 때는 장점이 아니다. 그럼 반대로 동적타입의 자바스크립트가 단점이 있다는 모순이 생긴다. 정적이건 동적이건 장단점이 있다. 즉, 동적이 주는 어느 이슈를 정적으로 보완해준다가 더 맞아 보인다. 만약 정적 타입이 장점이라고 가정한다면, 타입스크립트만으로는 답을 찾을 수 없다. 지금까지 자바스크립트가 동적 타입을 가지는 문제를 다른 방법으로 접근했지, 이를 제한하지는 않았다. 동적 언어의 최적화는 Javascript Hidden Classes and Inline Caching in V8 이 글을 참고하면 된다.
이 글은 개인적으로 최대한 객관적으로 접근을 시도하려 하시는 분 같았다. 물론 더 깊게 들어갔으면 하는 내 바램도 있지만, 그건 내 혼자만의 생각일 뿐이지만…
정말로 버그를 줄이고 싶다면 타이핑에 만족하지 말고, 테스트를 더 잘 짜는데 주력해야한다. 게다가 타입스크립트를 쓴다고해서 테스트를 안짜도 되는 것도 아니다.
특히 이 부분에 많이 공감한다. 에러나 버그는 테스트로 많이 줄일 수 있다. 그리고 글 아래에 함수형 프로그래밍을 언급하셨는데, 나는 함수형 프로그래밍을 선호하는 개발자라 함수를 만들면서 타입을 이미 대충 정하기에 그것 만으로도 많은 사이드 이펙트를 줄일 수 있다는 것을 몸으로 체감 했다. 그리고 테스트 도중에 의외의 문제를 많이 잡아줬다.
정적타입은 다시말해 장점이라 볼 수 없다. 그렇다면 React 에서 Mixin 의 단점을 보안하고자 HOC 패턴이 등장했는데,
Higher-order components (HOCs) in React are a powerful tool for code reuse between components. However, a common complaint of developers using TypeScript is that they are difficult to set types for.
타입의 제한이 하나의 문제 해결 방안을 다시 문제로 만드는 또 다른 상황을 만들었다. 즉, 내가 하고 싶은 말은 HOC 는 이미 자바스크립트의 특성 때문에 이전 문제를 해결 할 수 있는 방법을 제시해줬지만, 타입스크립트가 슈퍼셋이라면서도 자바스크립트의 어느 분야를 막아버리는 모순이 생겼다. 원래 자바스크립트를 이용한 해결책이 되었지만, 타입스크립트에서 다시 문제가 되었고 이를 해결하는 글이 생겼다는 것 자체가 자바스크립트의 슈퍼셋의 정의가 꼬인 모순이라는 것이다.
그리고 ES6 / ES Next 지원이 왜 장점인지 모르겠다. 안전하게 도입이라 말씀하셨는데, Babel 은 필요한 것만 가볍게 지원해준다고 하면 장점으로 바뀐다. 이는 아 다르고 어 다르다는 문제다. 아직 Draft 에 올라왔다는건 대부분 이전에 없던 것을 구현해주것만 있는게 아닌, Syntactic 슈가도 많이 있다. 대부분 이미 다른 방법으로 구현되어있다.
그리고 타입스크립트 도입이 두렵다고 하는 몇 글을 보면, 조금 이상하다. 두려워서 안하는게 아닌 필요가 없어서 안하는거다. 내 입장은 본인이 도입했으니 남들도 도입해야한다는 말을 조금 비꼰 내용 같아 보인다. 이는 링크를 첨부하고 싶지는 않다.
Reason 3 - Con?
타입스크립트를 좋게 바라보는 글은 쉽게 보이니, 다른 의견들을 모아봤다. 이들은 타입스크립트를 부정하는게 아닌, 타입스크립트를 찬양할 필요도 없다는 글이다. 이 글들은 링크만 남기겠다.
- Is TypeScript worth it?
- The TypeScript Tax
- After two years with TypeScript – was it worth it?
- The Good, The Bad, and The Ugly of TypeScript
- 7 really good reasons not to use TypeScript
Reason 4 - WASM
나는 동적인 타입으로 인해 생겼던 장점의 언어를 왜 정적으로 태생을 바꾸려고 하는 시도가 이상하게 보인다. 순수 자바스크립트로 해결할 수 있는 방법도 있었는데, 타입의 제한은 해결책을 다시 제한된 영역에서 다시 만들어 슈퍼셋 보다는 나는 장점의 어느 부분을 제한해버리는 언어 같아 보인다. 타입 자체에 문제를 느낀다면 차라리 다른 언어로 사용하여 WASM 으로 바꾸면 되는 간단한 문제가 아닐까 싶다. 크롬은 이미 WASM 을 지원하는 것으로 안다.
그리고 아마 물론 추측이지만, 내 생각은 MS 가 타입스크립트가 계속 성장하면 Edge 브라우저에서 알아서 파싱해주는 엔진을 만들거 같다. 그럴거면 브라우저의 JIT 컴파일러를 바꿔버리라 말하고 싶다. 그러면 나도 불만이 없어질거 같다. JIT 을 없애버리면 WASM 도 별로 장점이 되지 못할거라고 본다. 뭔가 이상하다.
생각보다 많이 써버렸다. 3 편을 또 작성할거 같은데 실제로 가능할지는 모르겠다.