(자알쓰) Scope Part. 1
자알쓰란?
자
바스크립트 알
고 쓰
자. (잘 쓰자는 의미도 담겨있다.)
자바스크립트라는 언어 자체는 내 기준에서는 설계 상 미스가 참 많다.
함수 단위의 스코프, 호이스팅, 동적 타입 등등
자바와 같은 깐깐(?)한 언어를 배우고 바라본 자스는 허점 투성이처럼 보였다.
애초에 자바스크립트는 어떠한 프로그램을 만들기 위해서 탄생했다기 보다는
웹 페이지에 입력값에 대한 유효성 검사(데이터가 공란인지 아닌지 등등)와 같은
페이지의 동적 제어가 주된 목적 + 짧은 개발 기간(넷 스케이프 사의 새로운 브라우저에 탑재 예정) 때문에
설계 상에 미스가 있을 수 밖에 없다고 나는 생각된다.
일종의 안전 장치가 없어서 개발자가 일일이 구현해주고, 신경써야 하는 느낌이었다.
그렇다고 해서 자바스크립트를 극혐하거나 그런 것은 아니고 매우 사랑한다.
또한 그 허점을 아는 사람은 허점을 보완해서 요리조리 피해서 잘 쓰겠지만…
잘 모르는 부분들은 잘못 써도 동작이 잘 되기 마련이다.
이는 지금 당장에는 큰 문제가 안 될지 모르겠지만, 추후에 대규모 웹 어플리케이션을 만들거나
직면할 문제로부터 미리 해방시키기 위해 처음부터 좋은 습관을 들여가는 것이 좋다고 생각한다.
그 세 번째 시리즈는 Scope(스코프)를 주제로 진행하겠다.
Scope? 스코프?
흔히 변수의 Scope라고 부른다.
(자알쓰) Hoisting
자알쓰란?
자
바스크립트 알
고 쓰
자. (잘 쓰자는 의미도 담겨있다.)
자바스크립트라는 언어 자체는 내 기준에서는 설계 상 미스가 참 많다.
함수 단위의 스코프, 호이스팅, 동적 타입 등등
자바와 같은 깐깐(?)한 언어를 배우고 바라본 자스는 허점 투성이처럼 보였다.
애초에 자바스크립트는 어떠한 프로그램을 만들기 위해서 탄생했다기 보다는
웹 페이지에 입력값에 대한 유효성 검사(데이터가 공란인지 아닌지 등등)와 같은
페이지의 동적 제어가 주된 목적 + 짧은 개발 기간(넷 스케이프 사의 새로운 브라우저에 탑재 예정) 때문에
설계 상에 미스가 있을 수 밖에 없다고 나는 생각된다.
일종의 안전 장치가 없어서 개발자가 일일이 구현해주고, 신경써야 하는 느낌이었다.
그렇다고 해서 자바스크립트를 극혐하거나 그런 것은 아니고 매우 사랑한다.
또한 그 허점을 아는 사람은 허점을 보완해서 요리조리 피해서 잘 쓰겠지만…
잘 모르는 부분들은 잘못 써도 동작이 잘 되기 마련이다.
이는 지금 당장에는 큰 문제가 안 될지 모르겠지만, 추후에 대규모 웹 어플리케이션을 만들거나
직면할 문제로부터 미리 해방시키기 위해 처음부터 좋은 습관을 들여가는 것이 좋다고 생각한다.
그 두 번째 시리즈는 Hoisting(호이스팅)을 주제로 진행하겠다.
Hoisting? 호이스팅?
이 처음보는 단어는 뭐지 싶을 수도 있다.
(자알쓰) ECMASCript? ES?
자알쓰란?
자
바스크립트 알
고 쓰
자. (잘 쓰자는 의미도 담겨있다.)
자바스크립트라는 언어 자체는 내 기준에서는 설계 상 미스가 참 많다.
함수 단위의 스코프, 호이스팅, 동적 타입 등등
자바와 같은 깐깐(?)한 언어를 배우고 바라본 자스는 허점 투성이처럼 보였다.
애초에 자바스크립트는 어떠한 프로그램을 만들기 위해서 탄생했다기 보다는
웹 페이지에 입력값에 대한 유효성 검사(데이터가 공란인지 아닌지 등등)와 같은
페이지의 동적 제어가 주된 목적 + 짧은 개발 기간(넷 스케이프 사의 새로운 브라우저에 탑재 예정) 때문에
설계 상에 미스가 있을 수 밖에 없다고 나는 생각된다.
일종의 안전 장치가 없어서 개발자가 일일이 구현해주고, 신경써야 하는 느낌이었다.
그렇다고 해서 자바스크립트를 극혐하거나 그런 것은 아니고 매우 사랑한다.
또한 그 허점을 아는 사람은 허점을 보완해서 요리조리 피해서 잘 쓰겠지만…
잘 모르는 부분들은 잘못 써도 동작이 잘 되기 마련이다.
이는 지금 당장에는 큰 문제가 안 될지 모르겠지만, 추후에 대규모 웹 어플리케이션을 만들거나
직면할 문제로부터 미리 해방시키기 위해 처음부터 좋은 습관을 들여가는 것이 좋다고 생각한다.
그 첫 번째 시리즈는 ECMAScript(이하 ES)를 주제로 진행하겠다.
ES의 탄생 배경
브라우저 전쟁 시절 개발자들은 몸살을 앓았다.
넷 스케이프 사의 자바스크립트가 부러웠는지 사용자 층을 더 끌어내기 위해 MS의 IE 3에도 JScript라는 이름으로 자바스크립트를 탑재하였다.
하지만 둘의 내용이 매우 달랐는지, 같은 기능을 구현하기 위해 개발자가 해야하는 일들이 더 많아졌다.
날이 가면 갈 수록 사용자를 끌어내기 위해 서로 기능을 넣다보니 Javascript와 JScript는 날이 가면 갈 수록 달라지는 경향을 보였다.
이에 대한 심각성을 파악하고, European Computer Manufacturers Association(ECMA, 현 ECMA International)에서는
이러한 자바스크립트에 대한 표준을 내리게 된다.
또한 ECMA에서는 자바스크립트의 표준만 내리는 게 아니라 다른 표준안도 정하기 때문에 그와 구분하기 위해 숫자를 붙였는데 262다.
ECMA262라고 보인다면 아, 자바스크립트 표준 규격이구나
라고 생각하면 될 것 같다.
ES6 Generator
들어가기에 앞서
이 포스트는 GDG 2016에서 발표하신 맹기완 님의 발표를 듣고 감명을 받아 정리해본 글이다.
(ES6) Interface와 (ES6) Symbol, (ES6) Iterator에 대한 내용은 링크를 참조하도록 하자.
사용 사례
이 사용 사례가 전부는 아니겠지만, 제너레이터는 이터레이터를 구현할 때 좀 더 쉽게 만들어준다.
우리는 지난 포스트에서 다음과 같이 배열의 요소를 거꾸로 사용하는 이터레이터를 구현해보았다.
(ES6) Iterator
들어가기에 앞서
이 포스트는 GDG 2016에서 발표하신 맹기완 님의 발표를 듣고 감명을 받아 정리해본 글이다.
(ES6) Interface와 (ES6) Symbol에 대한 내용은 링크를 참조하도록 하자.
또한 이 글을 다 읽고 나서 ES6 Generator도 읽어보자.Iterator는 반복자
란 뜻을 가지고 있으며, 대충 반복과 관련된 용어라는 것만 알고 글을 읽어보자.
다음에 나오는 예제는 이터레이터를 쓴다.
ES6에서는 다음과 같은 문법에서 알게 모르게 이터레이터를 쓰고 있다.
(Webpack 2) 상대경로 헬파티에서 탈출하기
(Webpack 2) 최적화하기
들어가기에 앞서
이 포스트들에서 말하는 내용들은 전부 배포용 파일에 적합한 작업이다.
이런 압축 작업을 개발용 버전에서 매번 빌드할 때마다 실행하면 빌드 시간이 매우 느려지기 때문이다.
우리는 (Webpack 2) 트리 쉐이킹을 해보자!에서 모듈 전체가 로딩 되는 CommonJS 방식에서
모듈의 필요한 부분만 로딩하는 ES2015 Native Module 방식을 사용하는 법을 배웠다.(Tree Shaking)
또한 (Webpack 2) 코드를 분할해보자!에서 공통된 라이브러리를 분리시켜 사용자가 재접속시 캐싱을 적극 활용하게 바꿨고,
모든 페이지의 코드를 로딩하는 것이 아닌 페이지를 이동할 때마다 필요한 소스만 로딩하게 끔 청크 별로 코드를 분할하였다. (Code Splitting)
그리고 Webpakc 2가 미완성이라 코드 스플리팅이 제대로 되지 않아 일일이 필요한 모듈 파일을 하나씩 명시해줬어야 했는데,
이를 좀 더 똑똑하게 해주는 바벨 플러그인을 소개한 내용을 (Webpack 2) 트리 쉐이킹을 똑똑하게 해보자! 통해서 보았다.
이번 포스트에서는 이와 더불어 조금이라도 더 소스 코드를 최적화하는 방법을 소개하도록 하겠다.
별로 안 대단해보일 수 있지만, 필자는 상당히 흥미롭게 느낀 내용이다.
혹시 위 3개 포스트를 보지 않은 사람은 따라하지는 않더라도 꼭 읽어보길 바란다.
예제는 아래 깃헙 저장소의 hot-3 브랜치를 기준으로 진행된다.
https://github.com/perfectacle/react-router-4/tree/hot-3
(ES6) Symbol
(Webpack 2) 트리 쉐이킹을 똑똑하게 해보자!
들어가기에 앞서
이 포스트는 (Webpack 2) 트리 쉐이킹을 해보자!의 후속작이다.
따라서 해당 포스트를 읽고 예제를 진행한 후에 보는 걸 추천한다.
또한 내가 리액트 말고 할 줄 아는 게 별로 없어서 예제를 리액트로만 진행하다보니
혹시 헷갈리면 다른 라이브러리로 진행해보길 바란다.
복습
우리는 지난 포스트에서 리액트 라우터를 트리 쉐이킹하였다.
아래와 같이 기존에 쓰던 방식대로 진행하면 쓰지도 않는 모듈들이 전부 번들링되는 참사가 발생한다.