어느날 개발자가 우리도 타스 좀 쓰자고 말했다...!? 타입스크립트에 조련 당하면 다시는 돌아갈 수 없습니다. 니꼬가 그랬어요. #JavaScript #TypeScript #Programming .. 📌 무료 타입스크립트 기초 강의 (+한글자막 지원) bit.ly/3vu93zo . 📌 무료 자바스크립트 기초 강의 (+한글자막 지원) bit.ly/37XEokK
Thanks for this informative video! Out of curiosity, why JS foundation doesn't update those problems mentioned in your video such as creating syntax for types?
항상 좋은 영상 감사합니다 ㅎㅎ 니꼴라스님에게 궁금한 점이 하나 생겼어요! 예전에 올린 맥북을 쓰는 이유에 대한 영상은 봤었지만 최근들어 노트북을 구매해야하는데 매우 큰 고민이 생겼습니다. M1으로 바뀐 맥북이 성능이 매우 강력하기 때문에 좋다고하는데 16년간 윈도우만 사용하다보니 넘어가기가 두렵기도 합니다…! 적응에 대한 문제점, 한국에서의 활용성등을 제쳐두고 성능만으로도 개발자로써 맥북을 사야할 강력한 이유가 따로 있는것인가요..!?
개인적인 생각입니다만, macOS를 써야하는 명확한 이유가 없다면 굳이 추천하진 않습니다. (개발환경이 macOS인 1인) - 웹 프론트 개발 시 Safari까지 고려하고 있는가? - 애플 생태계의 앱을 개발하는가? (아이폰, 아이패드, 맥북, 애플워치...) - 리눅스는 쓰기 싫은데 리눅스 friendly한 환경에서 개발하고 싶은가? - 디자이너와 자주 협업하는 일을 하는가? (높은 색재현도가 필요하거나 macOS를 우선지원하는 프로토타입 도구를 쓰는 경우) - 기타 macOS 생태계가 아니면 쓰지 못하는 소프트웨어를 쓰고 싶을 경우 (파이널컷, 로직X 등등) - 대부분의 게임이 지원되지 않는걸 장점이라고 생각하는 경우
최근에 js 공부를 단기간에 빡세게 했는데, js를 공부하면서 '요즘엔 ts가 대세라던데 js에만 몰두하는게 아닐까' 잠시 의구심이 들었어요. 그래도 웹의 근간은 js라고 생각해서 js부터 탄탄하게 하자는 마음가짐이었는데 역시 일단 js부터 확실히 하고 넘어가는 것이 맞겠네요 :) 얼른 ts라는 방패를 착용하고 싶어요.. ☻🛡
@@elliemion C랑 파이썬까지는 배웠던 터라 타입 캐치하는것의 중요성을 인지하고있는데, ts공부할때 타입체킹해줘서 좋았다는 뜻이에요. 삽질하다보면 js코드를 자주 보게되는데 var만 가지고 놀길래 너무 달라보이기도 했고요. js문법을 아예 모르는건 아니지만 현업에 쓸만큼은 아니라서 공부하려는 중입니다
@@user-vf1tj3vg6s 원래 한글은 한자처럼 띄어쓰기가 없이 따닥따닥 붙여서 사용했었습니다. 가독성과 의미전달에 어려움이 있어서, 영어처럼 띄어쓰기를 도입한 것입니다. 저 분은 가독성과 단어구분, "자바스크립트"라는 단어가 눈에 더 잘 띄도록 강조하기 위하여, 저렇게 쓰는 것입니다. 한글을 몰라서 저러는 것이 아닙니다. 님이 한글에 띄어쓰기가 도입되기 전에 살았고, 띄어쓰기를 한 사람을 발견했다면... 이렇게 말했을 것임. "그래서 그걸 틀렸다고 지적한 거예요~"
현재 it 서버 인프라 쪽 생각중인 학부생입니다 진로 방향을 틀게되어 처음부터 다시 준비해야하는 상황입니다 2년밖에 시간이 없어서 좀 조급합니다만..IT분야가 워낙 미래 산업인건 알고있는데 서버쪽도 괜찮을까요? 현재 파이썬 다시 공부중이며 aws 공부도 할려고 합니다(AWS가 유명해서,,) 전공자들은 1학년떄부터 한걸 전 중간에 진로를 바꾸게되서 좀 자신감도 없어지네요 ㅠ
파이썬을 하던지, 자바를 하던지, JS를 하던지 간에 특정 언어 하나를 선택해서 파다 보면 자연스레 시야가 트이는 것 같네요..! 저 같은 경우엔, 개념을 잡는데 시간이 오래 걸려서인지 이 언어 저 언어 맛보기를 많이 해봤더니 남는게 없더라구요. 저도 컴공으로 편입해서 비슷한 처지인듯 하여 답글 남깁니다...ㅎㅎ 작년 1년 엄청 허덕이고 지금도 꽤나 열심히 허덕이는 중입니다 ㅎㅎ.. ㅠ 파이팅 하세요!!
타입스크립트 너무 좋아요. 원래 자바쪽이어서인지 자바스크립트의 타입 없는 게 너무 힘들고 적응하기 어려웠음. 타입스크립트로 interface 등을 만들 때도 옵셔널(?)을 사용하지 않으려 노력 중... 타입스크립트의 장점은 코드 수정의 두려움이 없어지는 것 같음. 하나 수정하면 알아서 다 디버깅으로 알려 줌. 자바스크립트는 하나 수정하는 것도 너무 무서워 ㅋㅋㅋ.
StrongType 랭귀지를 주력으로 하는 개발자로서, TS를 써보고 정말 좋다고 생각하는 부분은 타입으로 인한 오류의 감소 및 생산성 향상도 있지만 '스크립트' 언어의 장점을 혼용해서 사용할 수 있다는 점입니다. 예를 들어 컴파일 언어에서 타입의 이름이나 프로퍼티명을 가져오는 행위는 상당히 까다로운데 TS는 XXX.constructor 라는 간단한 구문으로 너무나 손쉽게 가져올 수 있거든요
안녕하세요 니꼴라스. 오늘도 유익한 영상 잘 봤습니다. 니콜라스가 올려준 영상은 아주 유익하고 흥미로운 주제가 많습니다. 그래서 길을 가는 도중이라던지, 운동을 하는 도중이라던지 운전하는 중에 듣고 싶어요 하지만 저를 포함해 많은 사람들이 영어 듣기가 안되다 보니 많이 아쉽습니다. 무언가를 하면서 멀티플레이로 들을 수 있는 라디오 컨텐츠도 꼭 개발해주세요. 니콜라스!
자바스크립트를 10년 넘게 사용하면서 딱히 불편하다던가 문제점이 피부로 와닿진 않았습니다. 물론 자바나 시샵처럼 완벽한 느낌은 없었지만요. 그러나 몇달전부터 타입스크립트를 이용해 프론트앤드와 백앤드 같이 사용하고 있는데, 왜 자바스크립트가 문제였는지 확실히 깨닫게 되더라구요. 특히 백앤드는 NestJS를 사용했는데, 자바기반의 스프링을 거의 완벽히 대체할수 있습니다. 사실, 타입스크립트가 자바나 자바스크립트보다 훨씬 낫다고 생각하는데 아직도 많이 유명하지 않는 이유를 모르겠네요.
타입에 대해서 개발자의 실수를 방지한다는 것은 이제 이해했습니다. 그러나 어차피 TS는 JS로 compile이 되는데, 그 얘기는 JS가 진정한 객체지향(OOP)이 아닌 Prototype based 언어라는 것을 본질적으로 해결하지 못하지 않나요? 이 부분에 대해서 궁금합니다. How can TS be more Object Oriented (in a more fundamental way, not just as a syntactical sugar) than JS, after all it eventually compiles into JS?
완벽한 객체지향이란건 없구, 현업에서 객체지향은 모든 경우에서 사용되면서도, 모든 경우에서도 뺄수 있지만.. 핵심은 객체지향은 뭐랄까, 프로그래밍 언어의 밑바탕입니다. 배워두시면 100% 무조건 유용합니다. 하지만 나중에 천천히 배우셔도, 객체지향처럼 생각하시면서 코딩하시게 될거에요. 객체지향은 사람이 사물을 보는 방식을 코드로 표현했다고 보시면 되며, 은연중에 영향을 계속 받고 계실 거에요.
@@user-di1kc9qm4t 따로 걱정하실거는 없어요. class 막상 써보면 지금 하시는거랑 다른거는 없습니다. 정리 차이라고만 보시면 되어요. 뭐랄까.. 이전에는 책상에 이것저것 올려놨는데, 박스 가져와서 거기에 담는다고 생각하시면 됩니다. 그게 뭐 특별한 규칙은 아니잖아요. 정리 방법이 바뀐것이지. 그러니, 걱정마시고 맘편하게 접근하세요. 으차피 프로그래밍 언어 거기서 거기입니다.
쓸까 말까 고민하다가 씁니다. 언급된 내용은 es6에서 defineProperties get set과 asign과 call을 잘 혼용해서 사용하시면 encapsulation과 더불어 대부분 해결됩니다. Typescript에서 이런부분을 trans 하는과정에서 자동화 해줄 뿐입니다. javascript의 전신은 lips인데 lips는 그렇게까지 허접하지 않습니다. dom구조를 만들면서 Lips가 선택 됐습니다. 추가로 브라우저 프로그램 위에서 돌아가는 스크립트 언어는 복잡할 필요가 없습니다.... oop, 상속 등 복잡한 문제 없이 변수, loop, function, 선언 기타 간단한 기능 만 있으면 초기에는 큰 문제가 없었습니다. 10일 걸릴만 했다고 생각합니다.
자동화가 별로 대단한 게 아니라는 듯 말씀하시네요...? 추가로 문제의 핵심은 웹사이트가 발전하고 복잡해지면서, 10일 걸릴 만 했던 과거의 상황과 달라졌기 때문에, 다른 대부분의 언어들에서는 아주 간편하게 제공되는 기능을 불편하게 사용해야만 하는 JS의 한계가 들어난 것 아닌가요?
@@128idd 그렇군요 글중에 어떤 느낌을 받으신 모양인데 그럴수 있겠네요. 사람들은 다양한 감성을 갖고 있죠... 사실 댓글을 달까 말까 고민하다 올렸는데 ... 이유는 제작자가 이런 영상 만드는게 보통일이 아니라 힘들게 만들었을꺼고 Typescript의 긍정적인 면을 부각 시키고 있는데 현재의 흐름상 아주 크게 나쁜일은 아닌데 굳이 멘트를 올려서 제작자 의기 소침해지게 하는건 아닌가.. 하는 고민에서 였습니다. 다만 멘트를 달아야 겠다고 마음 먹은건 현재의 시점 상 결국 Typescript는 Javascript를 보조해 주는 역할인데 마치 영상의 내용은 Typescript가 Javascript의 대체제 인듯한 느낌을 받았고 Javascript는 문제가 있는 언어로 비춰지고 있는데 이런점은 Typescript와 Javascript의 관계를 생각했을때 paradox 로 생각되기 때문입니다. 주시할 점은 2018 es6까지 ECMA표준이 지속적으로 확장, 표준화가 진행 중이라는 점입니다. 초기 Netscape와 ie의 script 탄생 시점을 javascript의 정체성으로 보면 안됩니다. 어째든 최근 흐름을 잘 반영해주고 풀어주는 '니콜라스'님께 감사드립니다. 영상 잘보고 있어요.
전직장에서 JS 1년, 현직에서 리액트TS사용중인데 현직에서 리액트를 처음 접해서 그런지는 몰라도 죽을 것 같습니다...... (전직장에서는 특정 CRM플랫폼의 백엔드 로직이 JS라서 기존 JS의 최적화 및 유지보수를 담당했습니다) 조금만 삐끗하면 의미심장한 오류메시지를 던지니 계속해서 코드 자체의 구조를 보도록 요구합니다 덕분에 그럴싸하게 입력해도 그럴싸하게 오류메시지한테 탈탈 털립니다 (문제는 오류에 대한 내용을 상세하게 기술 안 해준다는 부분입니다. JS로 개발했을 떄의 벌어지는 에러해결시간에 비하면 TS가 확실히 그 부문에 대해서는 이점이긴 합니다만, 초심자 입장에선 대체 무슨 이유로 오류가 발생했는지 모르니 결국에는 JS로 개발했을 때 또는 그보다 더 많은 오류해결시간을 요구하게 됩니다) JS의 역사를 보니 넷스케이프는 평생 MS에게 고통만 받다가 잊혀진 회사로 남을 것 같습니다 넷스케이프는 한때 MS와 싸움판을 벌인 기록이 있는 회사였고 결국에는 넷스케이프가 도태되고 IE가 등극하면서 참담한 패배를 맛보게 되었는데 JS까지 저런 거로 봐선 뭔가 아이러니하네요
나는 ts 좋다고 생각한다. 협업에 아주 좋다고 생각한다. 하지만 혼자 개발할 때나 너무 뻔한 패턴이 있는 프로젝트는 js가 더 편하다. 왜냐하면 빠르게 코딩할 수 있다. 타입 때문에 생기는 문제는 생각보다 적다. try catch도 있고 instanceof도 필요할 때만 쓰면 된다. 대부분의 로직엔 타입이 필수가 아니다. 그리고 자바스크립트에서는 == 와 ===가 별개이고 truthy, falsy가 있어 이것들을 잘 활용하면 된다. 애초에 js는 간단한 로직을 만들기 위해 설계된 언어이다. 정교한 것을 만들려면 다른 언어를 쓰자.
니꼬 쌤이 JS를 쓰지 않는다니, 이게 무슨 소리야...! ...어그로를 잘 끄는 거보니 니꼬 쌤은 훌륭한 유튜버시군요... 8:57 니꼬 쌤이 처음에는 TypeScript 를 추천하지 않기도 했지만, 저 역시 결국 TypeScript는 마지막에 JavaScript 로 컴파일되어 화면에 보여진다는 것을 이해하는 것이 좋다고 생각하기 때문에, 처음부터 TypeScript 를 사용하는 것은 추천하지 않습니다. TypeScript 로 React 나 Vue 등의 프론트엔드 개발을 하게 되면 그게 희미해지긴 합니다만, 특히나 TypeScript 에 Any 타입이 존재하는 이유를 잘 생각하는 게 좋습니다.
점점 더 모든 웹 개발 주요 언어들이 컴파일 단계를 거치고 있음. html은 jsx, tsx, pug... css는 less, sass, scss... js는 coffee, type, 심지어는 자체 스펙내의 버전 호환을 위해서도 컴파일을 함. 이 비용을 감당할만큼의 이점이 있다고 하지만, 왜... 우린 그 컴파일을 당연하다고 받아들일까... 하는 의문도 가져야 할 듯. 인간의 생산성을 위해 sw의 복잡도가 높아지는 게 좋은 건지 의문.
자바스크립트에 느슨한 관계에 대해서 별로 불편함을 못느꼈던것 같습니다. 너무 직관적이나 단순하게 사용해서 일수도 있습니다. 계산이 필요한다거나 타입체크가 필요하거나 하는부분들은 제 3의 사용자들의 해킹에 의해서 변경될수도 있어서.. 대부분 뒷단으로 넘겨서 작업을 했었던것으로 기억합니다. 결국 타임스크립트도 마지막에는 자바스크립트 결국 자바스크립트를 완전히 걷어낼수는 없고.. 자바스크립트의 인기 요인은 느슨한 자유성이지 않을까 싶습니다. 너무 타입에만 고집하는 언어들은 개발자들이 싫어하더라구요.. 결국 나중가면 잘 사라지고... 아근데 자바는 엄청 살아남네요.. 언제사라지려나..
