2016년에 자바스크립트를 배우는 느낌

프레임워크가 만들어지지 . 본 기사를 쓰는 동안에는 JavaScript 않았습니다 읽을 수 있습니다 다음은 Circle CI의 기사 "It's the future"에서 영감을 받았습니다. 원본은 여기에서 . 이 글은 단지 의견일 뿐이며, 모든 JavaScript 프레임워크와 마찬가지로 너무 심각하게 받아들이지 말아야 합니다. 안녕하세요, 저는 새로운 웹 프로젝트를 시작했는데, 솔직히 말해서 저는 몇 년 동안 웹을 많이 코딩하지 않았고 풍경이 약간 바뀌었다는 소식을 들었습니다. 당신이 이 지역에서 가장 최신의 웹 개발자 맞죠? -실제 용어는 프런트엔드 엔지니어지만, 맞아요, 제가 맞는 사람이에요. 저는 2016년에 웹을 합니다. 시각화, 음악 플레이어, 축구를 하는 드론, 뭐든요. 방금 JsConf와 ReactConf에서 돌아왔기 때문에 웹 앱을 만드는 최신 기술을 알고 있어요. 멋지네요. 사용자의 최신 활동을 표시하는 페이지를 만들어야 하므로 REST 엔드포인트에서 데이터를 가져와서 필터링 가능한 테이블에 표시하고 서버에서 변경 사항이 있으면 업데이트하면 됩니다. jQuery를 사용하여 데이터를 페치하고 표시하는 게 어떨까요? -맙소사, 아무도 jQuery를 안 써요. React를 배워보세요. 2016년이에요. 오, 알겠습니다. React가 뭔데요? - Facebook의 몇몇 사람들이 만든 정말 멋진 라이브러리입니다. 모든 뷰 변경을 아주 쉽게 처리할 수 있게 해 주어 애플리케이션의 제어력과 성능을 높여줍니다. 멋진 것 같네요. React를 사용해서 서버의 데이터를 표시할 수 있나요? - 네, 하지만 먼저 웹페이지에 React와 React DOM을 라이브러리로 추가해야 합니다. 잠깐, 왜 도서관이 두 개나 있는 거지? - 하나는 실제 라이브러리이고 두 번째는 DOM을 조작하기 위한 것으로, 이제 JSX에서 설명할 수 있습니다. JSX? JSX는 무엇인가? -JSX는 XML과 매우 흡사한 JavaScript 구문 확장입니다. DOM을 설명하는 또 다른 방법이며, 더 나은 HTML이라고 생각하면 됩니다. HTML에는 무엇이 문제인가요? - 지금은 2016년입니다. 더 이상 HTML을 직접 코딩하는 사람은 없습니다. 맞아요. 어쨌든 이 두 라이브러리를 추가하면 React를 쓸 수 있나요? -그렇지 않아요. Babel을 추가해야 React를 사용할 수 있어요. 또 다른 도서관? 바벨이 뭐야? -아, Babel은 JavaScript의 특정 버전을 대상으로 지정하고, JavaScript의 모든 버전으로 코딩할 수 있게 해주는 트랜스파일러입니다. ReactJS를 사용하기 위해 Babel을 반드시 포함할 필요는 없지만, 포함하지 않는 한 ES5를 사용해야 하며, 현실적으로 2016년이기 때문에 다른 멋진 애들처럼 ES2016+로 코딩해야 합니다. ES5? ES2016+? 여기서 길을 잃어버리네요. ES5와 ES2016+는 뭐예요? -ES5는 ECMAScript 5를 의미합니다. 이는 오늘날 대부분의 브라우저에 구현되어 있기 때문에 대부분의 사람들이 타겟으로 삼는 버전입니다. ECMA스크립트? - 네, 알다시피, 스크립팅 표준 JavaScript는 1995년에 처음 출시된 후 1999년에 기반을 두었습니다. 당시 JavaScript는 Livescript라는 이름으로 Netscape Navigator에서만 실행되었습니다. 당시에는 매우 지저분했지만 다행히 지금은 상황이 매우 명확해졌고 이 구현의 7개 버전이 있습니다. 7개 에디션. 진짜요. 그리고 ES5와 ES2016+는요? -각각 5판과 7판입니다. 잠깐, 여섯 번째에는 무슨 일이 일어났는데? - ES6 말씀하시는 거예요? 네, 각 에디션은 이전 에디션의 슈퍼셋이에요. ES2016+를 사용한다면 이전 버전의 모든 기능을 사용하는 거예요. 맞아요. 그럼 왜 ES6 대신 ES2016+를 사용하나요? - 글쎄요, ES6를 사용할 수는 있지만, async와 await 같은 멋진 기능을 사용하려면 ES2016+를 사용해야 합니다. 그렇지 않으면 적절한 제어 흐름을 위해 비동기 호출을 차단하는 코루틴이 있는 ES6 생성기에 갇히게 됩니다. 방금 무슨 말씀을 하셨는지 전혀 모르겠고, 이 모든 이름이 혼란스럽습니다. 보세요, 저는 서버에서 데이터를 많이 로드하고 있을 뿐인데, CDN에서 jQuery를 포함하고 AJAX 호출로 데이터를 가져올 수 있었는데, 왜 그냥 그렇게 할 수 없는 걸까요? - 2016년이야, 아무도 jQuery를 안 써, 스파게티 코드로 끝나. 다들 알잖아. 맞아요. 그래서 제 대안은 세 개의 라이브러리를 로드하여 데이터를 가져오고 HTML 테이블을 표시하는 것입니다. - 글쎄요, 그 세 개의 라이브러리를 포함시킨 다음 모듈 관리자로 묶어서 하나의 파일만 로드하도록 하죠. 알겠습니다. 그리고 모듈 관리자는 무엇인가요? - 정의는 환경에 따라 다르지만, 웹에서는 일반적으로 AMD나 CommonJS 모듈을 지원하는 모든 것을 의미합니다. 그렇죠. 그리고 AMD와 CommonJS는…? - 정의. 여러 JavaScript 라이브러리와 클래스가 어떻게 상호 작용해야 하는지 설명하는 방법이 있습니다. exports와 require를 아시죠? AMD 또는 CommonJS API를 정의하는 여러 JavaScript 파일을 작성하고 Browserify와 같은 것을 사용하여 묶을 수 있습니다. 좋아요, 그럴 것 같아요… 제 생각에는요. Browserify가 뭐예요? - 브라우저에서 실행할 수 있는 파일에 CommonJS로 설명된 종속성을 번들로 묶을 수 있는 도구입니다. 대부분의 사람들이 npm 레지스트리에 해당 종속성을 게시하기 때문에 만들어졌습니다. npm 레지스트리? - 똑똑한 사람들이 코드와 종속성을 모듈로 넣어 놓은 매우 큰 공개 저장소입니다. CDN과 같나요? -그렇지 않아요. 누구나 라이브러리를 게시하고 다운로드할 수 있는 중앙 집중형 데이터베이스와 비슷해서, 로컬에서 개발에 사용한 다음 원하면 CDN에 업로드할 수 있어요. 아, 바워 같군요! - 네, 하지만 지금은 2016년이라 Bower를 사용하는 사람이 더 이상 없습니다. 아, 알겠습니다. 그러면 npm에서 라이브러리를 다운로드해야 하나요? -네. 예를 들어 React를 사용하고 싶다면 React 모듈을 다운로드하여 코드에 가져옵니다. 거의 모든 인기 있는 JavaScript 라이브러리에 대해 그렇게 할 수 있습니다. 오, Angular 같아요! -Angular는 2015년 스타일이에요. 하지만 그렇죠. Angular는 VueJS나 RxJS, 그리고 다른 멋진 2016년 라이브러리와 함께 거기에 있을 겁니다. 그것에 대해 알고 싶으신가요? React에 집중하자. 나는 이미 너무 많은 것을 배우고 있다. 그래서 React를 써야 한다면 npm에서 가져와서 Browserify를 쓰면 되는 거야? -예. 종속성을 잔뜩 잡아서 묶는 건 너무 복잡해 보이네요. -그렇습니다. 그래서 Grunt나 Gulp, Broccoli 같은 작업 관리자를 사용하여 Browserify 실행을 자동화하는 것입니다. 심지어 Mimosa도 사용할 수 있습니다. 으르렁? 꿀꺽? 브로콜리? 미모사? 지금 뭐에 대해 이야기하는 거야? - 작업 관리자. 하지만 더 이상 멋지지 않아요. 2015년쯤에 사용했고, 그 다음에는 Makefiles를 사용했지만, 지금은 모든 것을 Webpack으로 래핑합니다. Makefiles? C나 C++ 프로젝트에서 주로 사용되는 줄 알았는데요. -그래, 하지만 웹에서 우리는 복잡하게 만들고 기본으로 돌아가는 걸 좋아하는 것 같아. 우리는 매년 그렇게 해. 기다려, 1~2년 안에 웹에서 어셈블리를 할 거야. 하ぁ. Webpack이라는 걸 언급했나요? - 브라우저용 모듈 관리자이자 일종의 작업 실행기이기도 합니다. Browserify의 더 나은 버전과 같습니다. 오, 알았어요. 왜 더 나은가요? - 글쎄요, 더 나은 건 아니지만, 종속성을 어떻게 묶어야 하는지에 대해 더 의견이 있을 뿐입니다. Webpack을 사용하면 CommonJS뿐만 아니라 다양한 모듈 관리자를 사용할 수 있습니다. 예를 들어 네이티브 ES6 지원 모듈입니다. 저는 CommonJS/ES6에 관한 모든 것에 대해 매우 혼란스럽습니다. -모두가 그렇죠. 하지만 SystemJS에서는 더 이상 신경 쓸 필요가 없습니다. 예수 그리스도, 또 명사-js. 좋아요, 그리고 이 SystemJS는 뭐죠? - Browserify와 Webpack 1.x와는 달리 SystemJS는 여러 모듈을 하나의 큰 파일에 묶는 대신 여러 파일에 묶을 수 있는 동적 모듈 로더입니다. 잠깐만요, 저희는 라이브러리를 하나의 큰 파일로 빌드해서 로드하고 싶다고 생각했었어요! -그렇죠. 하지만 이제 HTTP/2가 등장했기 때문에 여러 개의 HTTP 요청이 실제로 더 좋습니다. 잠깐, 그럼 React의 원래 라이브러리 세 개를 그냥 추가할 수 없나요?? -그렇지 않아요. CDN에서 외부 스크립트로 추가할 수는 있지만, 그래도 Babel을 포함해야 합니다. 하ぁ. 그거 나쁜 일이죠? - 네, 바벨 코어 전체를 포함하게 되고 프로덕션에서는 효율적이지 않을 겁니다. 프로덕션에서는 사탄을 소환하는 의식을 삶은 달걀 요리법처럼 보이게 만드는 일련의 사전 작업을 수행하여 프로젝트를 준비해야 합니다. 자산을 최소화하고, 못생기게 만들고, 폴드 위에 인라인 CSS를 넣고, 스크립트를 지연시키고, 그리고- 알았어요, 알았어요. 그럼 라이브러리를 CDN에 직접 포함하지 않는다면 어떻게 할까요? - Webpack + SystemJS + Babel의 조합을 사용하여 Typescript에서 트랜스파일링할 것입니다. 타입스크립트? 우리가 자바스크립트로 코딩하는 줄 알았어! -타입스크립트는 JavaScript입니다. 또는 더 나은 표현으로 JavaScript의 슈퍼셋, 더 구체적으로는 ES6 버전의 JavaScript입니다. 아시죠, 우리가 전에 이야기했던 여섯 번째 버전 말이에요? ES2016+가 이미 ES6의 슈퍼셋이라고 생각했어요! 왜 지금 Typescript라는 것이 필요한 걸까요? -아, JavaScript를 타입 언어로 사용하고 런타임 오류를 줄일 수 있기 때문입니다. 지금은 2016년이고 JavaScript 코드에 몇 가지 타입을 추가해야 합니다. 그리고 Typescript는 분명히 그런 일을 합니다. - Flow도 마찬가지지만, Typescript는 컴파일이 필요한 JavaScript의 상위 집합인 반면, Typescript는 타이핑만 검사합니다. 하ぁ…그리고 플로우는? - Facebook의 몇몇 사람들이 만든 정적 유형 검사기입니다. 함수형 이 굉장하기 프로그래밍 때문에 OCaml로 코딩했습니다 . OCaml? 함수형 프로그래밍? -요즘 쿨한 애들이 쓰는 거잖아, 2016년 말이야? 함수형 프로그래밍? 고차 함수? 커링? 순수 함수? 방금 무슨 말씀을 하셨는지 전혀 모르겠습니다. -아무도 처음에는 하지 않아요. 보세요, 함수형 프로그래밍이 OOP보다 낫다는 것만 알면 되고, 2016년에 우리가 사용해야 할 것이 바로 그것입니다. 잠깐, 저는 대학에서 객체 지향 프로그래밍(OOP)을 배웠는데, 그것이 좋다고 생각했어요? -오라클에 인수되기 전 자바도 마찬가지였습니다. 제 말은, OOP는 옛날에는 좋았고 오늘날에도 여전히 쓰이고 있지만, 지금은 모두가 상태를 수정하는 것이 아기를 차는 것과 같다는 것을 깨닫고 있기 때문에, 지금은 모두가 불변 객체와 함수형 프로그래밍으로 옮겨가고 있습니다. Haskell 사람들은 수년간 그것을 부르고 있었고, -Elm 사람들은 말하지 않겠지만- 다행히도 웹에서는 Ramda와 같은 라이브러리가 있어서 일반 JavaScript에서 함수형 프로그래밍을 사용할 수 있습니다. 그냥 이름만 내세우는 거야? Ramnda가 뭔데? -아니요. 람다. 람다 같은 거요. 데이비드 챔버스의 도서관 말이에요? 데이비드 누구? -데이비드 챔버스. 멋진 남자. Coup 게임을 잘합니다. Ramda의 기여자 중 한 명입니다. 함수형 프로그래밍을 진지하게 배우고 싶다면 Erik Meijer도 확인해 보세요. 그리고 에릭 마이어는…? -함수형 프로그래밍 전문가이기도 합니다. 멋진 사람입니다. 그는 이상한 색 셔츠를 입고 Agile을 비판하는 프레젠테이션을 많이 합니다. Tj, Jash Kenas, Sindre Sorhus, Paul Irish, Addy Osmani의 작품도 꼭 확인해 보세요- 좋아요. 여기서 멈추겠습니다. 다 좋고 괜찮지만, 저는 이 모든 것이 데이터를 가져와서 표시하는 데 너무 복잡하고 불필요하다고 생각합니다. 동적 데이터로 테이블을 만들려면 이 사람들을 알거나 이 모든 것을 배울 필요가 없다고 확신합니다. React로 돌아가 봅시다. React로 서버에서 데이터를 가져오려면 어떻게 해야 합니까? -사실, React에서는 데이터를 가져오지 않고, 단지 표시만 할 뿐입니다. 오, 젠장. 그럼 데이터를 가져오는 데 뭘 써요? - Fetch를 사용하여 서버에서 데이터를 가져옵니다. 죄송한데요? Fetch를 사용해서 데이터를 가져오는 거예요? 그런 것들에 이름을 붙이는 사람은 동의어 사전이 필요해요. -맞아요? Fetch는 서버에 대해 XMLHttpRequests를 수행하기 위한 네이티브 구현의 이름이에요. 아, 그러면 AJAX군요. -AJAX는 단지 XMLHttpRequests를 사용하는 것입니다. 하지만 물론입니다. Fetch를 사용하면 약속에 기반한 AJAX를 수행할 수 있으며, 이를 해결하여 콜백 지옥을 피할 수 있습니다. 콜백 지옥? -그래요. 서버에 비동기 요청을 수행할 때마다 응답을 기다려야 하는데, 그러면 함수 안에 함수를 추가해야 하는데, 이것을 지옥의 콜백 피라미드라고 합니다. 오, 알겠습니다. 그리고 이 약속이 문제를 해결해 주나요? -그렇습니다. 약속을 통해 콜백을 조작하면 이해하기 쉬운 코드를 작성하고, 모의하고 테스트할 수 있으며, 동시에 여러 요청을 수행하고 모든 요청이 로드될 때까지 기다릴 수 있습니다. Fetch로 이런 작업을 할 수 있나요? - 예, 하지만 사용자가 에버그린 브라우저를 사용하는 경우에만 해당됩니다. 그렇지 않은 경우 Fetch 폴리필을 포함하거나 Request, Bluebird 또는 Axios를 사용해야 합니다. 도대체 몇 개의 도서관을 알아야 하나요? 몇 개나 되는 도서관인가요? - JavaScript입니다. 모두 같은 일을 하는 라이브러리가 수천 개는 있을 겁니다. 우리는 라이브러리를 알고 있고, 사실 우리는 최고의 라이브러리를 가지고 있습니다. 우리의 라이브러리는 엄청나고, 가끔은 Guy Fieri의 사진을 포함시키기도 합니다. 방금 Guy Fieri라고 했나요? 이걸 끝내자. Bluebird, Request, Axios 라이브러리는 뭐하는 거야? - 약속을 반환하는 XMLHttpRequests를 수행하는 라이브러리입니다. jQuery의 AJAX 메서드도 약속을 반환하지 않았나요? - 2016년에는 더 이상 "J"라는 단어를 사용하지 않습니다. Fetch를 사용하고 브라우저에 없는 경우 폴리필을 사용하거나 대신 Bluebird, Request 또는 Axios를 사용하세요. 그런 다음 async 함수 내에서 await로 약속을 관리하면 붐, 적절한 제어 흐름이 생깁니다. await를 언급한 건 벌써 세 번째인데 무슨 말인지 전혀 모르겠어요. -Await를 사용하면 비동기 호출을 차단하여 데이터를 페치하는 시점을 더 잘 제어하고 전반적으로 코드 가독성을 높일 수 있습니다. 대단합니다. Babel에 stage-3 사전 설정을 추가하거나 syntax-async-functions 및 transform-async-to-generator 플러그인을 사용하기만 하면 됩니다. 이건 미친 짓이야. -아니요, Typescript 코드를 미리 컴파일한 다음 Babel로 트랜스파일하여 await를 사용해야 한다는 사실이 미친 짓입니다. 뭐요? Typescript에 포함되지 않아요? - 다음 버전에서는 지원하지만, 버전 1.7 기준으로는 ES6만을 대상으로 합니다. 따라서 브라우저에서 await를 사용하려면 먼저 ES6을 대상으로 하는 Typescript 코드를 컴파일한 다음 Babel을 사용해 ES5를 대상으로 코드를 수정해야 합니다. 이 시점에서는 무슨 말을 해야 할지 모르겠습니다. -보세요, 쉽죠. 모든 것을 Typescript로 코딩하세요. Fetch를 사용하는 모든 모듈은 ES6을 대상으로 컴파일하고, stage-3 사전 설정에서 Babel로 트랜스파일하고, SystemJS로 로드합니다. Fetch가 없다면, 폴리필을 사용하거나 Bluebird, Request 또는 Axios를 사용하고, 모든 약속을 await로 처리하세요. 우리는 쉬움에 대한 정의가 매우 다릅니다. 그래서 그 의식으로 마침내 데이터를 가져왔고 이제 React로 표시할 수 있죠? - 귀하의 애플리케이션은 상태 변경을 처리할 것인가요? 어, 그럴 것 같지 않아요. 그냥 데이터를 표시하면 돼요. - 오, 신이시여. 그렇지 않으면 Flux와 Flummox, Alt, Fluxible과 같은 구현을 설명해야 했을 겁니다. 하지만 솔직히 말해서 Redux를 사용해야 합니다. 저는 그 이름들을 그냥 날아갈 겁니다. 다시 말하지만, 저는 그저 데이터를 표시하면 됩니다. -아, 데이터만 표시한다면 처음부터 React가 필요 없었을 겁니다. 템플릿 엔진이 있어도 괜찮았을 겁니다. 농담이에요? 이게 재밌다고 생각하세요? 사랑하는 사람을 그렇게 대하는 거예요? - 저는 그냥 무엇을 사용할 수 있는지 설명해드린 것 뿐입니다. 멈춰. 그냥 멈춰. - 제가 당신이었다면 템플릿 엔진만 사용하더라도 Typescript + SystemJS + Babel의 조합을 사용했을 겁니다. 저는 Sub Zero의 원래 MK fatality를 수행하는 것이 아니라 페이지에 데이터를 표시해야 합니다. 어떤 템플릿 엔진을 사용해야 하는지 말씀해 주시면 제가 처리하겠습니다. -많은데, 당신이 익숙한 것은 무엇입니까? 으악, 이름이 생각나지 않아요. 오래전 일이거든요. -jTemplates? jQote? PURE? 어, 기억이 나지 않네요. 또 하나 더요? -투명성? JSRender? MarkupJS? KnockoutJS? 그건 양방향 바인딩이 있었어. 또 하나? -PlatesJS? jQuery-tmpl? Handlebars? 아직도 사용하는 사람들이 있어요. 아마도요. 마지막 것과 비슷한 게 있나요? -콧수염, 밑줄? 솔직히 말해서 지금은 lodash에도 하나 있는 것 같지만, 그건 2014년의 일종이에요. 어.. 아마 더 최신이었을 거예요. -제이드?더스트JS? 아니요. -DotJS? EJS? 아니요. - 수녀크? 전기충격요법? 아니요. -어차피 아무도 Coffeescript 구문을 좋아하지 않잖아. 제이드? 아니, 당신은 이미 제이드라고 말했잖아요. - 퍼그를 말하려고 했어요. 제이드를 말하려고 했어요. 제이드는 이제 퍼그예요. 하ぁ. 아니요. 기억이 나지 않습니다. 어떤 걸 쓰시겠어요? -아마도 ES6 네이티브 템플릿 문자열일 겁니다. 추측해 봅시다. 그리고 ES6이 필요합니다. -옳은. 어떤 브라우저를 사용하느냐에 따라 Babel이 필요할 수도 있습니다. -옳은. 전체 핵심 라이브러리를 추가하지 않고 포함하려면 npm에서 모듈로 로드해야 합니다. -옳은. 그러려면 Browserify나 Wepback이 필요하고, 아니면 SystemJS라고 불리는 다른 것이 필요할 가능성이 큽니다. -옳은. Webpack이 아닌 이상 이상적으로는 태스크 러너가 관리해야 합니다. -옳은. 하지만 함수형 프로그래밍과 타입이 있는 언어를 사용해야 하므로 먼저 Typescript를 미리 컴파일하거나 Flow라는 것을 추가해야 합니다. -옳은. 그리고 await를 사용하고 싶다면 그것을 Babel로 보내면 됩니다. -옳은. 그러면 Fetch, Promise, Control Flow 등 모든 마법같은 것들을 사용할 수 있죠. - Fetch가 지원되지 않는다면 폴리필을 사용하는 것을 잊지 마세요. Safari에서는 여전히 처리할 수 없습니다. 알아요. 여기서 끝낼 것 같아요. 사실, 끝낼 것 같아요. 웹도 끝났고, 자바스크립트도 다 끝났어요. - 괜찮아요. 몇 년 안에 우리 모두 Elm이나 WebAssembly로 코딩하게 될 거예요. 저는 백엔드로 돌아갈 겁니다. 저는 이렇게 많은 변경 사항과 버전과 에디션과 컴파일러와 트랜스파일러를 감당할 수 없습니다. JavaScript 커뮤니티가 이걸 따라갈 수 있다고 생각한다면 미친 짓입니다. -알겠습니다. 그럼 파이썬 커뮤니티를 시도해 보세요. 왜? -Python 3에 대해 들어보신 적이 있나요? 에서 토론 중입니다 업데이트: 오타와 실수를 지적해 주셔서 감사합니다. 지적한 대로 기사를 업데이트하겠습니다. HackerNews 와 Reddit .