이제는 라이브러리는 TypeScript 시대에서 JSDoc 시대로...
사실 진짜 중요한 것은 자바스크립트 생태계에서 라이브러리 코드를 작성하는 패러다임이 바뀌고 있다는 것입니다.
라이브러리 엔지니어는 라이브러리 소비자를 위해 타입 지정의 책임이 있습니다.
타입스크립트를 사용하면 컴파일 시간이 극단적으로 길어질 수 있습니다. 라이브러리를 엔지니어링 한다는 것은 브라우저를 위해 공급하는 것과 조금 다릅니다. 코드 베이스의 규모가 극단적으로 거대해지기 쉽습니다.
DHH의 타입혐오
타입 혐오자 DHH의 또 기막힌 결정이 나왔습니다.
Turbo 8 is dropping TypeScript - DAVID HEINEMEIER HANSSON
By all accounts, TypeScript has been a big success for Microsoft. I've seen loads of people sparkle with joy from dousing JavaScript with explicit types that can be checked by a compiler. But I've never been a fan. Not after giving it five minutes, not after giving it five years. So it's with great pleasure that I can announce we're dropping TypeScript from the next big release of Turbo 8.
여러 후기들에 따르면 타입스크립트는 MS에게 거대한 성공이었습니다. 저는 컴파일러에 의해 확인될 수 있는 명시적인 타입들로 자바스크립트를 사용하는 것으로 인해 많은 사람들이 기뻐하는 것을 보았습니다. 하지만 저는 팬이 아니었습니다. 5분 동안 시도한 후, 5년 사용한 후에도 아니었습니다. 그래서 저는 큰 기쁨으로 Turbo 8의 다음 큰 릴리스에서 타입스크립트를 제거한다는 소식을 전합니다.
The fact is that I actually rather like JavaScript. I'd go so far as to say it's my second favorite language after Ruby. Yes, a distant second, but a second none the less. This wasn't always the case. But after we got proper classes in JavaScript, and all the other improvements that flowed since ES6, it's become a real joy to write.
사실 저는 자바스크립트를 더 좋아합니다. 저는 Ruby 다음으로 좋아하는 언어입니다.. 네, 아주 가까운 2번째이고 더도 말고 덜도 말고입니다. 항상 이런 경우는 아니었습니다. 자바스크립트에 적절한 class가 추가되고 다양한 개선들이 ES6 이후 도입된 이후로 작성하기 즐거운 언어가 되었습니다.
I still don't think JavaScript is well-suited for most of the work we do on the server side of the web-app equation, but fully respect and appreciate that others feel differently. To me, it's simply our good fortune that we now have such a capable JavaScript, which browsers are able to interpret without any need for a compiler at all.
저는 아직도 웹 어플리케이션 개발 방정식에서 서버 측 작업은 대부분의 경우 자바스크립트가 잘 맞지 않는다고 생각합니다. 하지만, 다른 사람들이 다르게 느끼고 생각하는 것을 완전히 존중하고 감사하게 여깁니다. 제게 있어서 브라우저가 컴파일러 없이 해석할 수 있는 이렇게 능력 있는 자바스크립트를 가지게 된 것은 우리의 행운이라고 생각합니다.
TypeScript just gets in the way of that for me. Not just because it requires an explicit compile step, but because it pollutes the code with type gymnastics that add ever so little joy to my development experience, and quite frequently considerable grief. Things that should be easy become hard, and things that are hard become
any. No thanks!
저의 입장에서 타입스크립트는 방해만 됩니다. 단순히 컴파일 단계가 있는 것만이 문제는 아닙니다. 코드를 타입 기계체조로 오염시킨다는 점이 개발경험에 즐거음보다 슬픔이 더 많았습니다. 원래 쉬워야 하는 것들이 어려워졌습니다. 그리고 어려운 작업들은 any로 해결했습니다. 이런거 필요 없습니다!
This isn't a plea to convert anyone of anything, though. As I discussed in Programming types and mindsets, very few programmers are typically interested in having their opinion on typing changed. Most programmers find themselves drawn strongly to typing or not quite early in their career, and then spend the rest of it rationalizing The Correct Choice to themselves and others.
하지만 이것은 그 어떤 것도 바꿔놓자는 부탁이 아닙니다. 제가 프로그래밍 유형과 사고방식에서 논의했듯이, 전형적으로 타입에 대한 자신의 의견을 바꾸는 데 관심이 있는 프로그래머는 극소수입니다. 대부분의 프로그래머들은 타입 지정하는 것에 강하게 끌리거나 일을 시작하는 초기 단계가 아니라는 것을 깨닫고, 자신과 다른 사람들에게 올바른 선택을 합리화하는 데 나머지 시간을 보냅니다.
That's part of the magic of this JavaScript v TypeScript dichotomy, and full credit to the TypeScript gang for realizing that a full take-over of JavaScript was never going to happen, so complete compatibility had to be baked in from the start. Just because Turbo 8 is dropping TypeScript won't mean you can't write your client code in it, or use any other library that employs it. We get to mix and match, which is wonderful.
이것이 바로 자바스크립트 대 타입스크립트 이분법의 마법의 일부이며, 타입스크립트 집단이 자바스크립트를 완전히 인수하는 일은 절대 일어나지 않을 것이기 때문에 처음부터 완전한 호환성이 필요했다는 것을 깨달은 것에 전적으로 공을 돌립니다. Turbo 8이 타입스크립트를 떨어뜨린다고 해서 그 안에 클라이언트 코드를 쓸 수도, 그것을 사용하는 다른 라이브러리를 사용할 수도 없다는 것을 의미하는 것은 아닙니다. 우리는 섞여서 일치하게 되는데, 이것은 정말 멋진 일입니다.
It's also necessary. Because unlike languages like Ruby, which are languages of choice when it comes to the server side, JavaScript is a language of necessity when it comes to the client side. While you may compile dialects into it, you still have to accept the fact that running code in the browser means running JavaScript. So being able to write that, free of any tooling, and free of any strong typing, is a blessing under the circumstances.
그것은 또한 필요하다. 서버 쪽에서 선택할 수 있는 언어인 Ruby와 같은 언어들과는 달리 클라이언트 쪽에서 자바스크립트는 필수 언어이기 때문입니다. 방언들을 여기에 컴파일할 수도 있지만 브라우저에서 코드를 실행하면 자바스크립트가 실행된다는 사실을 받아들여야 한다. 따라서 이러한 상황에서 도구 없이, 강력한 타이핑 없이 그것을 쓸 수 있다는 것은 축복입니다.
So farewell, TypeScript. May you bring much rigor and satisfaction to your tribe while letting the rest of us enjoy JavaScript in the glorious spirit it was originally designed: Free of strong typing.
잘가라, 타이프스크립트. 당신의 부족에게 많은 엄격함과 만족감을 가져다 주고, 자바스크립트가 원래 설계된 영광스러운 정신으로 즐기게 해 주시기를 바랍니다. 강한 타입지정으로 부터 자유로운.
물론 이해할 수 있는 부분도 있습니다. 라이브러리 코드를 작성할 때 타입 지정을 하기 type gymnastics 기예를 보여줘야 합니다.
DHH는 누구인가?
DHH는 누구인가? RoR(Ruby on Rails) 프레임워크를 만든 사람입니다. 오늘날 MVC 패턴으로 웹개발하는 프레임워크 개발한 사람으로 우리가 일하는 방식의 패러다임을 바꾼 사람입니다.
하지만 특이한 부분이 있는데 원래부터 타입지정 정적인 타입 검증을 싫어하는 사람입니다.
커뮤니티의 반응
fireship
타입스크립트는 성공했는가?
라이브러리는 코드베이스에서 drop하기 시작했습니다.
tl;dr 라이브러리 코드는 자바스크립트는 JSDoc으로 어플리케이션 코드는 타입스크립트로 작성합니다.
Theo
ThePrime
레포를 터치기도 했나봅니다.
Rich Harris
removing types from your own code is clownish, epically misguided behaviour, but whatever — to each their own. removing types from a library THAT OTHER PEOPLE HAVE TO USE, however, is just user-hostile dickwaddery
https://twitter.com/Rich_Harris/status/1699490194565578882
결론
Remove TypeScript - hotwired의 turbo
지금 한참 인기많은 PR입니다. 여기는 이제 언따봉과 shit posting의 성지입니다.
오늘도 오픈소스 생태계는 평화롭습니다.