이 글은 https://herbsutter.com/2023/10/09/my-new-cppcon-talk-is-on-youtube-cooperative-c-evolution-toward-a-typescript-for-c/ 에서 영감을 받있습니다.

브라우저 내에서 사용되기를 원한다는 점에서 Dart와 TypeScript 모두 Javascript 자리를 노리는 언어이다. 두 언어 모두 브라우저 내에서 동작하는 언어를 목표로 한다. 그러면서 기존에 있던 언어인 Javascript의 Type Safety를 비롯한 문제들을 각자의 방법으로 수정했다.

JS의 문제를 해결하기 위해 Dart는 새로운 언어를 만들었다. Dart와 JS는 원하는 위치는 같지만 아예 별계의 언어이다. 그렇기 때문에 JS에는 없는 기능들이 들어간다. Typescript는 JS 위에 문법을 추가함으로서 JS의 문제를 일부 수정하려고 한다. Dart와 달리 TypeScript는 Javascript에서의 확장을 표방한다. 그 연장선에서 TS에서는 별도의 작업 없이 JS를 직접 끌어 쓸 수 있다.

두 언어 모두 JS 대신에 사용되려는 목표는 같다. 그러나 접근 방식이 사뭇 다르다. Dart는 “새로운 언어”를 들고 왔다. JS로의 변환은 어디까지나 옵션이다. 대신에 JS에 있는 모든 문제점을 자기들 입맛대로 해결 할 수 있다.

그와 반대로, TypeScript는 “기존에 있는 언어(JS)의 확장” 이라는 방향으로 접근 한다. 언어에 정적 문법을 추가함으로서 언어의 문제점을 수정한다. 이 방식은 기존 Javascript의 모든 문제를 해결해 주지는 않는다. 대신 기존 레거시 코드를 그대로 사용할 수 있게 한다. 물론 원하면 적은 노력으로 기존 코드에 Typescript의 기능을 가져올 수도 있다.

어떤 문제점을 아예 새로운 것(언어)을 만듦으로서 해결하는 방식을 Dart Plan, 기존에 있는 것에 기능을 확장함으로서 해결하는 방식을 TypeScript Plan이라고 부를수 있다.

문제를 해결하기 위해 아예 새로운것을 도입할 때는 전환 비용이 발생한다. 하위 호환성을 포기해야 할 때는 더 큰 비용이 발생한다. 전환 비용은 저항이 되어 계속해서 발목이 잡힌다. 하위 호환성을 무시할 수 없기 때문이다.

예를 들어서, Bootstrap은 2에서 3으로 올라갈때 시장에서 받아드리는데 수 년이 걸렸다. Python3는 2008년에 나왔지만, 2020년 초반만 해도 Python2 코드가 작성 됐다. Flutter 2때의 라이브러리중 일부는 1.5년이 지나도록 업데이트가 되지 않아서 문제이다. 필자도 이것 때문에 Flutter2에 남아 있어야 하나… 꽤나 고민 했었다.

결론적으로 기존 시스템을 대체하는 방식 대신에, 기존 시스템과 잘 어울려가는 방식이 훨씬 좋다. 당연하게도 하위 호환성이 유지된다. 기존 시스템과 협력적으로 돌아가기 때문에 다시 처음부터 쌓아올릴 필요가 없다. 기존 시스템이라는 기초를 쓸 수 있기 때문이다.

물론 문제점들이 많아지면 많아질 수록 아예 새로운 것을 만들자는 압력이 높아진다. 그럼에도 불구하고 “기존의 것에 확장”을 추구하는것이 어려운 선택이지만 더 나은 선택이 될 수 있을 것이다.