Javascript 2016

http://www.looah.com/article/view/2054: 2016년에 자바스크립트를 배우는 기분이라는 글을 보게 됐다. 자바스크립트가 주 언어다 보니 굉장히 많이 이 링크를 지인들로부터 건내받았는데, 여기에 언급된 용어들을 간단하게 정리해볼까 한다.


 

React페이스북에서 만든 라이브러리이다. MVC 모델에서 V를 담당하며 React의 흐름을 조작하는 아키텍쳐  개념으로 페이스북은 Flux를 제시했고, Flux의 구현체로는 주로 Redux를 사용한다. 최근에 가장 핫-한 Front-end Framework임과 동시에 막강한 생태계, 꽤 괜찮은 성능, 프레임워크 자체가 잘 만들어졌다는 장점을 가진다.

React는 엄청나게 느린 DOM manipulation을 피하기 위해 필요한 부분만 O(n)의 알고리즘으로 찾아내서 그 부분만을 조작해서 HTML를 직접 다루는 오버헤드를 최소화하는 virtual DOM 이라는 개념과 구현체를 만들었고 그것이 곧 ReactDOM이다.

그래서 React에서 virual DOM tree를 관리하게 되는데, 그 tree의 node를 생성하는 데에 순수한 자바스크립트로 만들면 가독성이 너무 떨어지더라, 가독성을 높이기위해 HTML 비슷한 무언가를 만들자! 하고 나타난 것이 JSX이며, JSX를 그대로 유저에게 전송한다면 유저의 브라우저에서 알아먹을 턱이 없을테니 그것을 다시 순수한 Javascript로 바꿔주는 것이 Babel Transpiler이다.

Babel은 비단 JSX 뿐만 아니라 더 최신의 표준으로 쓰여진 Javascript를 옛날 하위 버전으로 바꿔주는 역할을 해줘서 최신의 문법으로 코딩하는 것을 도와주는 아주 고마운 transpiler! es5, es6, es2016+ (es7) 은 그 문법들의 버전이라고 생각하면 되는데, Java로 치면 1.6, 1.7, 1.8. C++로 치자면 C++11, C++14의 그것들과 같은 녀석들이다.

그리고 여러가지 라이브러리를 다운받고 각각의 의존성을 해결하는 도구Bower, NPM등을 사용했는데 요즘 추세는 npm을 많이 사용하는 것 같다. 나도 딱히 이유는 모르겠는데, 아마 bower가 모든 의존성을 flat하게 관리하는데, bower는 서로 다른 두 개의 라이브러리에서 한 라이브러리의 A 버전과 B 버전을 요구하는 경우에 둘 중에 하나를 고르게 만들더라고. 이게 문제가 아닐까 싶다.

태스크 매니저는 전부 다는 모르지만, (…) Grunt, Gulp 정도를 알고 있는데, Grunt가 약간 레거시같은 느낌. 속도와 생산성 면에서 파이프 개념을 쓰는 Gulp가 더 좋다고 하는데 이것들을 써서 프로젝트의 캐시를 비우거나, 서버를 돌리거나, 배포 버전으로 서버를 돌리거나, 배포 버전의 파일들을 빌드한다거나, 테스트를 돌리거나, 문법을 검사한다는 식의 태스크를 만들어서 지루한 터미널 명령어들을 자동화할 수 있게 도와준다.

모듈 번들러BrowserifyWebpack을 사용하는데, browserify가 npm의 스펙을 지키지 않는다였나, 그리고 webpack의 diff cache가 엄청나게 빠르고 확장성이 괜찮아서였나.. 최근 대세는 확실히 webpack인 듯. SystemJS도 모듈 로더라고 하는데 잘 모르겠다. 아직 불안정하다고 들어서 자세히 알아보진 않았음.

webpack으로 CommonJS에서 쓰는 require(), ES6부터 지원하기 시작한 import 문들을 사용할 수 있게 되며, 이외에도 single page application의 늦은 초기 로딩을 해결하기 위해 파일들의 의존성을 잘 파악해서 여러개의 모듈로 쪼갤 수 있게 도와주기도 함. 플러그인을 붙이기에 따라서 태스크 매니저를 대체할 수 있을 정도의 빠-와를 가지고 있다고 생각.

TypeScript는 타입이 있는 Javascipt로 마이크로소프트에서 주도하는 오픈소스 스크립트언어다. 개인적으로 Front-end 개발의 미래는 Typescript라고 생각하고 있지만, C에서 각종 변수와 함수들의 타입의 프로토타입들을 선언해놓은 헤더파일과 비슷한 ‘무언가’가 없으면,  javascript로 쓰여진 라이브러리를 typescript에서 사용할 수 없다는 아주 치명적인 단점이 있다.

이는 1~2년 안에 해결되지 않을까… 사실 지금도 definitely typed를 보면 충분히 성숙됐다고 하는데, 내가 겪어야할 러닝커브를 더 높히고 싶지 않더라고. 지금 쓰는 라이브러리도 안 익숙한데 예제 코드도 얼마 없고, 손에 익지도 않은 typescript로 작성할 생각을 하니 무서워서ㅎㅎ…

AJAX라는 밈이 뜬 이유는 XMLHttpRequest라는 표준이 생기면서 부터였는데, 이를 좀 더 가다듬은 새로운 표준이 fetch이며 이 표준이 구현되어있지 않은 예전 브라우저들에서도 같은 코드를 사용하기 위해 만들어진게 fetch-polyfill 이다. fetch를 사용하지 않을거라면 다른 XMLHttpRequest를 추상화해준 라이브러리들을 사용하는 것이 좋으며, 대표적인 라이브러리로 axios가 있다.

AJAX를 다루기 위해 Promise가 나왔는데, 이것과 es6에서 구현된 generator를 이용해서 비동기적인 코드를 꽤나 동기적인 느낌으로 작성할 수 있게 되었고 다시 이것을 좀 더 쓰기 쉽고 읽기 편하게 바꾸어준 것이 async/await이라고 한다. (나도 아직 이 부분이 많이 헷갈린다..)

그리고 템플릿 엔진은 아직 본격적으로 다뤄보지 않아서 패스한다. 본문에서도 react를 쓰면 딱히 필요없다고 쓰여있기도 했고. >_<.. 이쪽은 Back-end에 조금 더 가까운 느낌이라 넘어가도 넘어가주시리라 믿음!

 


 

여기에 쓰인 것은 Front-end를 적당히 이해하기에 필요한 내용들이고 깊게 들어갈 부분은 많이 없다. 적당히 Gulp와 Webpack의 사용법만 이해하면 될 듯. 그리고 이런 모든 기술들을 조합해서 프로젝트 환경을 세팅하는것은 굉장히 힘든 일이다. 이를 해결하기 위해서는 yeoman를 사용하도록 하자. 내가 추천하는 범용적인 yeoman generator는 generator-fountain-webapp이니 참고하면 좋을 듯.

사실 이번에 react로 프로젝트를 새로 빌드하면서 사용한 react 라이브러리를 정리하려다가, 2016년에 자바스크립트를 배우는 기분이라는 글을 만나게 되면서 기본기를 한 번 정리하고 같는 것도 재밌겠더라고. 그래서 끄적끄적 침대에 누워서 노트북으로 작성해봤는데, 틀린 부분이 있다면 댓글로 알려주시길!

Leave a Reply