Ts Ssibal Ts
M$의 더러운 ts에 오염된 js 생태계
사악한 타입스크립트의 광신도들 때문에 자유로운 js가 오염되고 있다. js는 막코딩 하려고 쓰는건데 거기다 타입을 넣겠단 발상 자체가 틀려먹었다
ts는 태생부터 잘못됐다. 따로 만들었어야지 아니면 과감하게 js를 리뉴얼 했어야 했다. 오래된 브라우저에 내장된 js에 호환되게 하려면 어쩔 수 없다고 할 수도 있긴한데.. 그러려면 ts의 변환도구를 좀 더 엄격하게 만들었어야지
백엔드에서는 원래 쓸모없고 프론트엔드에서 웹어셈블리의 발전만 막았다.
대규모, 깔끔한, 타입코드
본좌는 타입있는 깔끔한 코딩을 원한다면 ts가 아닌 java,kotlin,go를 써야 한다고 지속적으로 주장 해 왔다 프론트엔드에서 그런게 필요한게 본적은 없지만(백엔드개발자라…) 있다면 js를 발전시키던가 웹어셈블리를 빨리 발전시키던가 했어야지
타입있는 js를 위해 ts를 쓴다고?? 파이썬으로 객체지향 한답시고 클래스 만드는 것 보다 어리석은 짓이다. 아닌가.. 파이썬으로 객체지향,클래스 쓰는건 좀 도움이 되기도 한다.
대규모 어쩌고 하는데 대규모 대용량 하려면js가 아닌 다른걸 쓰는게 좋다. 메모리 사용량이 좋은 go, 안정적인 런타임 프레임웤라이브러리를 가진 spring
그런데 타입스크립트는 아무리 봐도 쓸모가 없고 오버헤드만 생긴다. 이쪽 시장은 생태계마저도 조악하다. 사용자가 많아진 덕분에 이것저것 나오긴 했는뎅… 죄다 커뮤니티에서 시작된거라 맨날 리뉴얼이야 그리고 라이브러리 제작자들도 js로 만들지 ts로 만들지 애매해서 애매하다. 다들 대혼란
애매해서 쓸모없는 TS
성능이 좋은 것도 아니고 IDE지원이 빵빵하지도 않아 실행이 편한것도 아니고 디버깅이 쉽지도 않아
컴파일 언어 장점이…
- ide에서 에러체크 잘 되고
- 컴파일타임 오류 발견되고
- … 등등 그런데 타입스크립트는 애매한게 엄밀히 따지면 컴파일 언어도 아니네 장점이 하나도 없다.
그냥 타입 좀 쓰겠다고 이렇게까지 고생을 한다고???
enum도 애매하게 지원하고
린트 없으면 아무것도 안된다. 컴파일이 아니라 트랜스파일transpile이라서 린트에 의존할 수 밖에 없나?? 린트를 빡빡하게 쓸 것 같으면 es6이후의 js를 쓰는것과 별 차이가 없다. es7이나 8정도에 타입을 강제 지정하는 기능을 넣는다면 타입스크립트는 완벽하게 사라져도 된다.
좆같은 경험
enum이 되는 줄 알았는데 안됐던 것 같은 기억이 dto에 duck typing으로 리턴값을 넣게 되는데 이렇게 하면 컴파일타임 오류가 제대로 안나온다고 prisma같은걸로 쿼리를 날릴 때 entity클래스를 따로 생성해야 하나? 왜 자동생성이 안되는지 jpa보다 나을게 없다. spring보다 편하지가 않다.
린트 없으면 아무것도 안되고… js는 너무 자유로워서 린트가 잘 안되나? js에서 린트 빡빡하게 넣으면 ts보다 나을 것 같은데 타입표시도 py처럼 거의 힌트수준이라 그냥 쑤셔넣으면 대충 들어가기도 하고.. duck typing되는것도 줫같네 레퍼런스 코드 따라가려서 컨트롤클릭F12등등 해 보면.. 이상한 타입코드로 가고 뭐가뭔지 알 수 없는 코드를 보여준다
ide도움으로 어떻게 참으면서 해보려고 했는데 진짜 못해먹겠다. 세번째 도전 완전포기.. 역시 서버는 go, kotlin으로 해야한다. 회사에서 쓴다면 진짜 참고 쓰겠는데 개인프로젝트나 창업기업에서 typescript 서버 쓰는건 진짜 병신짓 아닐까
쉽다고 하면 쉽긴쉬운데… 쉬운걸 쓰려면 js로 해야하고 ts를 쓰면 말도안되는데서 에러나서 짜증나는게 더 크지 않나? prisma 수정하면 반영도 바로 안되고 딜레이는 뭐 이렇게 걸리는지