과거에 JavaScript를 배우는 것은 어땠나요?-JS 튜토리얼-php.cn

안녕하세요, 최근에 웹 프로젝트를 받았는데, 솔직히 지난 2년 동안 웹 프로그래밍을 접한 적이 거의 없었습니다. 당신이 여기에서 신기술에 대해 가장 잘 아는 웹 개발자라고 들었습니다.

정확하게 말하면 "프론트엔드 엔지니어"입니다. 하지만 당신은 적합한 사람을 찾았습니다. 저는 올해의 기술, 프런트엔드 시각화, 음악 플레이어, 축구를 할 수 있는 드론에 대해 잘 알지 못합니다. 그냥 물어보세요. 방금 JS 컨퍼런스와 React 컨퍼런스에 갔는데, 모르는 신기술이 하나도 없습니다.

멋지네요. 글쎄요, 저는 사용자들의 최신 업데이트를 표시하는 웹페이지를 개발하고 싶습니다. 백엔드 인터페이스를 통해 데이터를 가져온 다음 테이블을 사용하여 데이터를 표시하면 사용자가 데이터를 정렬할 수 있어야 한다고 생각합니다. 서버의 데이터가 변경되면 이 테이블도 업데이트해야 합니다. 내 생각은 jQuery를 사용하여 수행하는 것입니다.

jQuery를 사용하지 마세요! 요즘에는 jQuery를 사용하는 사람이 없습니다. 지금은 2016년이고 여러분은 반드시 React를 사용해야 합니다.

아, 그렇군요. React란 무엇인가요?

React는 Facebook의 재능 있는 사람들이 작성한 매우 강력한 라이브러리입니다. 페이지를 보다 쉽게 제어할 수 있고 성능이 뛰어나며 사용하기 쉽습니다.

정말 좋은 것 같아요. React를 사용하여 서버의 데이터를 표시할 수 있나요?

물론 종속성 두 개만 추가하면 됩니다. 하나는 React이고 다른 하나는 React DOM입니다

음, 잠깐만요, 왜 라이브러리가 두 개 있나요?

제가 말하는 라이브러리는 React이고, DOM을 운영하기 위해서는 React DOM을 사용합니다. 이러한 DOM은 JSX로 작성되었기 때문에 이를 조작하려면 특수 라이브러리가 필요합니다.

JSX? JSX란 무엇입니까?

JSX는 JS의 확장으로 XML과 유사하며 HTML을 작성하는 데 사용할 수 있습니다. JSX는 HTML을 작성하는 더 우아한 방법이라고 생각할 수 있습니다.

HTML을 사용하면 어떨까요...?

지금은 2016년인데 HTML을 직접 작성하는 사람은 없습니다.

그렇습니다. 좋아요, 이 두 가지 종속성을 추가한 후 React를 사용할 수 있나요?

아닙니다. React를 사용하려면 먼저 Babel을 추가해야 합니다.

바벨은 또 다른 도서관인가요?

바벨은 여러분이 작성한 JS를 모든 버전의 JS로 번역할 수 있는 번역 도구입니다. 반드시 Babel을 사용할 필요는 없지만, 사용하지 않는다면 ES5 구문을 작성해야 합니다. 2016년인데 어떻게 ES2016+ 구문을 사용할 수 없나요? ES2016+는 정말 멋지네요.

ES5란 무엇인가요? ES2016+란 무엇입니까? 좀 어지러워요.

ES5는 ECMAScript 5입니다. 대부분의 브라우저가 ES5를 지원하기 때문에 대부분의 사람들은 ES5를 사용합니다.

ECMAScript란...

아시다시피 JS는 1995년에 탄생했고, JS 표준은 1999년에 제정되었습니다. 그 당시 JavaScript는 여전히 Livescript라고 불리며 Netscape 브라우저에서만 실행될 수 있었습니다. 혼란스러운 시기였지만 이제 JS 사양에는 7가지 버전이 있습니다.

7가지 버전? ES5와 ES2016+는 어떻습니까?

는 각각 5번째 버전과 7번째 버전입니다.

야, 여섯번째 버전은 어때?

ES6에 대해 이야기하고 계십니다. 각 버전은 이전 버전의 상위 집합이므로 최신 ES2016+를 사용하면 됩니다.

그렇습니다. ES6를 사용하지 않는 이유는 무엇입니까?

ES6을 사용할 수는 있지만 async 및 wait의 멋진 구문을 사용할 수는 없습니다. ES2016+를 사용하는 것이 더 좋습니다. ES6에서는 생성기를 사용하여 비동기 작업 흐름을 제어할 수 있습니다.

무슨 말씀인지 모르겠어요... 제가 이해할 수 없을 만큼 명사를 너무 많이 말씀하셨어요. 서버에서 일부 데이터를 가져오고 싶습니다. 예전에는 jQuery를 잘 사용했는데, CDN에서 jQuery를 도입한 후에는 AJAX를 사용하여 데이터를 가져올 수 없나요?

형님, 지금은 2016년인데 jQuery를 사용하는 사람이 아무도 없군요. 그렇죠? jQuery를 사용하면 "스파게티" 코드(관리 불가능)만 생성된다는 것은 누구나 알고 있습니다.

자, 이제 데이터를 가져와 표시하려면 세 개의 라이브러리를 로드해야 합니다.

예, 실제로 "모듈 관리자"를 사용하여 이 세 라이브러리를 하나의 파일로 "패키지"할 수 있습니다.

아, 모듈 관리자가 뭐죠...

모듈 관리자는 플랫폼마다 다릅니다. 프런트엔드 모듈 관리자는 일반적으로 AMD 또는 CommonJS 모듈을 관리하는 것을 말합니다.

그럼... AMD와 CommonJS가 뭐죠?

은 두 가지 정의입니다. 내보내기 및 요구 사항과 같이 JS에서 여러 라이브러리 또는 클래스의 상호 작용을 설명하는 방법은 다양합니다. AMD 또는 CommonJS API에 따라 JS를 작성한 다음 Browserify로 패키징할 수 있습니다.

합리적으로 들리네요. 그런데 Browserify 란 무엇입니까?

은 JS 파일을 CommonJS 형태로 패키징하여 브라우저에서 실행하는 데 사용되는 도구입니다. npm 저장소를 사용하는 사람들이 CommonJS를 발명했습니다.

npm 저장소란...

은 종속 모듈을 배치하는 데 사용되는 공개 저장소입니다.

CDN 같은 건가요?

같지 않습니다. 이는 모든 사람이 코드를 게시하고 코드를 다운로드할 수 있는 데이터베이스에 가깝습니다. 개발 중에 사용하기 위해 이러한 코드를 로컬로 다운로드하거나 필요한 경우 CDN에 업로드할 수 있습니다.

바우어 같군요!

그렇습니다. 하지만 지금은 2016년이고 더 이상 Bower를 사용하는 사람이 없습니다...

알겠습니다. npm을 사용하여 종속 항목을 설치해야 합니다.

맞습니다. 예를 들어보겠습니다. React를 사용하려면 npm을 사용하여 직접 React를 설치한 다음 코드에서 React를 가져올 수 있습니다. 대부분의 JS 라이브러리는 이 방법으로 설치할 수 있습니다.

음, Angular도 작동합니다.

Angular는 2015년입니다. 하지만 올해 Angular는 죽지 않았습니다. VueJS와 RxJS 등도 있습니다. 배우고 싶나요?

React를 사용해 봅시다. 나는 이제 충분히 배웠다. 그럼 npm으로 React를 설치하고 Browerify로 패키징할까요?

그렇습니다.

좀 너무 복잡한 것 같습니다.

그렇습니다. 이것이 바로 Browserify를 자동으로 실행할 수 있는 Grunt, Gulp 또는 Broccoli와 같은 작업 관리 도구를 사용해야 하는 이유입니다. 아니요, 이제 Mimosa를 사용할 수 있습니다.

무슨 소리야...

작업 관리 도구. 하지만 우리는 더 이상 그것을 사용하지 않습니다. 작년에도 계속 사용하다가 나중에 Makefiles로 변경했는데 지금은 모두 Webpack을 사용하고 있습니다.

저는 C/C++ 프로젝트만 Makefile을 사용하는 줄 알았습니다.

그렇습니다. 하지만 웹 개발에 종사하는 우리는 먼저 일을 복잡하게 만든 다음 가장 간단한 상태로 돌아가는 것을 좋아합니다. 우리는 매년 이것을 합니다. 2년 안에 우리는 웹에서 편집물을 작성할 수 있게 될 것입니다.

방금 말씀하신 Webpack이 무엇인가요?

또 다른 모듈 관리 도구이자 작업 관리 도구입니다. Browserify의 향상된 버전이라고 생각하면 됩니다.

아, 왜 Webpack이 향상된 버전인가요?

뭐, 강화가 안 된 것일 수도 있겠네요. Webpack은 종속성을 관리하는 방법을 알려줍니다. Webpack을 사용하면 CommonJS뿐만 아니라 ES6 모듈도 지원하는 다양한 모듈 관리자를 사용할 수 있습니다.

여기저기서 모든 일이 일어나고 혼란스러워요.

다들 헷갈리시겠지만 SystemJS가 나올 때까지 기다려주세요.

맙소사, 또 다른 JS 라이브러리, 이게 대체 뭐죠?

ㅋㅋㅋ Browserify나 Webpack 1.x와 달리 SystemJS는 동적 모듈 로더입니다.

잠깐만요, 제가 방금 모든 의존성을 하나의 파일로 묶어야 한다고 말하지 않았나요?

그렇게 말하지만 HTTP/2가 대중화되면 패키징하지 않는 것이 나을 것 같습니다.

그럼 React의 세 가지 종속성 파일을 페이지에 직접 추가하는 것은 어떨까요?

아닙니다. CDN에서 이러한 파일을 로드할 수 있지만 여전히 Babel을 사용하여 로컬로 번역해야 합니다.

아, 정말 안됐나요?

예, 프로덕션 환경에서 Babel을 실행할 수 없습니다. 프로덕션 환경에 게시하기 전에 압축, 난독화, 인라인 CSS, 스크립트 지연 로딩 등 일련의 작업을 실행해야 합니다.

알겠습니다, 이해합니다. CDN을 직접 사용할 수 없는데 어떻게 해야 하나요?

Typescript를 트랜스파일하기 위해 Webpack + SystemJS + Babel을 사용하는 것을 고려해 보겠습니다.

타입스크립트? 우리는 JavaScript에 대해 이야기하고 있지 않습니까? !

Typescript는 JS보다 사용하기 쉽고 JS의 상위 집합입니다. 이는 우리가 방금 이야기한 ES6입니다.

ES2016+는 이미 ES6의 상위 집합인데 Typescript가 다시 나타나는 이유는 무엇입니까?

그렇습니다. Typescript를 사용하면 "강력한 형식의" JS를 작성할 수 있으므로 런타임 오류가 줄어듭니다. 2016년에는 JS가 강력한 타이핑을 지원해야 할 때입니다.

분명히 Typescript가 할 수 있을 것 같습니다.

Flow도 이를 수행할 수 있습니다. 차이점은 Typescript를 컴파일해야 하는 반면 Flow는 구문만 확인한다는 것입니다.

야, 플로우?

은 Facebook 사람들이 작성한 정적 유형 검사기입니다. OCaml을 사용하여 작성된 함수형 프로그래밍은 매우 쉽습니다.

OCaml? 함수형 프로그래밍?

요즘 2016년에는 대기업들이 이런 것들을 사용하고 있습니다. 함수형 프로그래밍, 고차 함수, 커링, 순수 함수 같은 개념이요.

무슨 말씀인지 모르겠습니다.

처음에는 아무도 몰랐어요. 이렇게 말하면 함수형 프로그래밍이 객체지향 프로그래밍보다 낫다는 것만 알아야 하며 2016년에는 함수형 프로그래밍을 지적했습니다.

잠깐, 저는 대학에서 객체지향 프로그래밍을 공부했는데 꽤 좋다고 생각했어요.

Java는 Oracle에 인수되기 전에는 꽤 좋았습니다. 내 말은, 예전에는 객체지향이 좋았고, 아직도 그것을 사용하는 사람들이 있지만, 이제 모든 사람들이 상태 변환이 유지하기 어렵다는 것을 알게 되었고, 그래서 모두가 "불변 객체"와 함수형 프로그래밍을 사용하기 시작했습니다. 하스켈 사람들은 오랫동안 이런 것들을 사용해 왔지만 다행히도 웹 개발 분야에는 JS를 사용하여 함수형 프로그래밍을 수행할 수 있는 Ramda와 같은 라이브러리가 있습니다.

명사 몇개 더 버린건가요? 람난다란 무엇인가요?

람다가 아니라 람다인데 약간 람다 표현과 비슷해요. David Chambers가 작성한 라이브러리입니다.

누구?

데이비드 챔버스, 대단한 사람이에요. blablabla

방해해야겠어요. 이것들은 모두 좋아 보이지만 너무 복잡하고 불필요하다고 생각합니다. 나는 단지 데이터를 가져와서 표시하고 싶을 뿐입니다. 이 경우에는 지식이 필요하지 않다고 확신합니다.

React로 돌아가서 React를 사용하여 서버에서 데이터를 어떻게 가져오나요?

글쎄, React는 이 기능을 제공하지 않으며, React를 사용하여 데이터를 표시할 수만 있습니다.

확신합니다. 그러면 데이터를 어떻게 얻을 수 있나요?

Fetch API를 사용하면 됩니다.

대체 뭐야? 이 API의 이름은 끔찍합니다.

저도 그런 것 같아요. Fetch API는 브라우저에서 제공하는 비동기 요청 인터페이스입니다.

아, AJAX군요.

AJAX는 XMLHttpRequest 객체만 사용하지만 Fetch API를 사용하면 Promise 스타일을 사용하여 비동기 요청을 시작할 수 있으므로 "콜백 지옥"을 제거하는 데 도움이 됩니다.

콜백 지옥?

예, 비동기 요청을 할 때마다 응답을 기다려야 합니다. 이때 함수 안에서 함수를 사용해야 하는데, 이 중첩된 호출은 콜백 지옥이다.

알겠습니다. Promise가 이 문제를 해결하나요?

그렇습니다. Promise를 사용하여 콜백을 관리하면 더 읽기 쉽고 테스트하기 쉬운 코드를 작성할 수 있습니다. 동시에 여러 요청을 하고 모두 반환될 때까지 기다릴 수도 있습니다.

Fetch도 똑같이 할 수 있나요?

그렇습니다. 하지만 전제는 사용자가 새 버전의 브라우저를 사용해야 한다는 것입니다. 그렇지 않으면 Fetch "폴리필"을 추가하거나 Request, Bluebird 또는 Axios와 같은 라이브러리를 사용해야 합니다.

맙소사, 라이브러리가 몇 개나 필요한가요?

이것은 JS입니다. 동일한 작업을 수행하는 라이브러리가 수천 개 있습니다. 우리는 도서관을 알고 있으며 최고의 도서관을 보유하고 있습니다. 우리는 수많은 도서관을 보유하고 있으며 원하는 것은 무엇이든 얻을 수 있습니다.

방금 말씀하신 도서관은 무슨 일을 하나요?

이 라이브러리는 XMLHttpRequest를 작동하고 Promise 객체를 반환합니다.

jQuery의 ajax 방식도 그런 것 같네요...

2016년부터 jQuery를 사용하지 않습니다. Fetch를 사용하는 경우 Polyfill을 추가해야 할 수도 있습니다. 그렇지 않으면 Bluebird, Request 또는 Axios를 사용할 수 있습니다. 그런 다음 비동기 작업을 제어할 수 있도록 대기 및 비동기를 사용하여 Promise를 관리합니다.

기다린다는 말이 벌써 세 번째네요.

await를 사용하면 비동기 호출을 차단할 수 있으므로 비동기적으로 반환되는 데이터를 더 효과적으로 제어할 수 있어 코드 가독성이 크게 향상됩니다. wait는 사용하기 매우 쉽습니다. Babel에서 stage-3 구성을 추가하거나 구문 비동기 기능 및 변환 비동기 생성기 플러그인만 추가하면 됩니다.

미친 소리 같군요.

미친 게 아닙니다. Wait를 사용하기 위해 Typescript를 컴파일한 다음 Babel을 사용하여 번역하는 사람들은 미친 짓입니다.

대체 뭐야? Typescript는 대기를 지원하지 않습니까?

다음 버전에서 지원될 예정입니다.

할 말이 없습니다.

사실 아주 간단합니다. Typescript를 사용하여 코드를 작성하고, Fetch를 사용하여 비동기 요청을 시작하고, 모든 코드를 ES6으로 컴파일한 다음 Babel의 stage-3 구성 항목을 사용하여 ES6를 ES5로 변환합니다. 모든 코드는 SystemJS를 사용하여 로드됩니다. Fetch를 사용할 수 없는 경우 폴리필을 추가하거나 Bluebird, Request 또는 Axios를 사용하여 Wait를 사용하여 Promise를 처리할 수 있습니다.

'단순'에 대한 이해가 다르다는 걸 보니. 자, 이제 드디어 React를 사용하여 데이터를 가져와서 표시할 수 있게 되었습니다. 그렇죠?