Next 웹 프론트엔드 세미나, 그거 좀 쓰면 더 좋냐?

스피커 : SK planet 윤지수 마스터

  • React, Flux, Gulp, ES6로 트렌디한 이야기를 해보겠다.
  • 이것들이 정말 필요한가? 필요한 시기인가? 이것에 대해 이야기 해보겠다.
  • 안써도 될 텐데… 이것들의 가치가 뭘까?

ES6

  • 새로운 feature와 syntax를 다룰 것.
  • 주요 feature
    • arrows : var pairs = evens.map(v => ({even :…)) 왠 화살표냐..
    • let : C와 같이 block scope로 선언. 굳이 필요한가..?
    • classes : java 프렌들리한 키워드들. class, extends, constructor, super, get 등.. function constructor & prototype, typescript 정도..?
    • module : export, import requireJs & browserify & webpack
    • modules loader : System.import().then(function(m) { … } system.js
    • Promises : .then 으로 이어가서 콜백을 잇도록.. 브라우저에서는 견딜만한 중첩콜백, promise 라이브러리가 따로 있기도 하고.. 브라우저에서는 굳이 많이 쓸까..? node에서 음.
    • yield, : function generator(i) { yield i + 1l yield* anotherGenerator(i); }, 이것은 함수 내부에서 멈추고 외부에서 실행을 제어할 수 있다. oh..? 브라우저에서 애니메이션을 제어할만할 것 같은데…
  • ES 6는 웹의 혁신이 아니라 자연스러운 진화라고 본다.
  • BABEL 등 transpiler는 ES6 -> ES5로 변환하는 역할을 수행하므로 대부분의 브라우저에서 호환될 수 있다.
    • Babel 은 가벼운 웹 애플리케이션에서는 필요 없다. transpiler는 비교적 무거울 수 있다.
    • classes, module, mouler loader 등이 필요한 무거운 웹 앱일 때 ES6를 사용하여 개발할 때 매력이 있다.

React

  • view에 집중하는 framework
  • UI 개발은 무엇인가? 결국 View 개발이다. jsp, thymeleaf 등 결국 뷰를 조작하기 위함이다. 그런데 왜 UI 개발에 MVC가 필요한가? data가 중요하다보니 Model이 의미를 가지게 되었고, Controller로 View와 Model을 이어주는 역할이 덩달아 필요해졌다.
  • 그러니까 data의 유지가 필요 없다면, 프레임워크를 쓸 필요가 없다. 이들은 무겁고 느리다. 신중하게 판단해야한다.
  • 싱글 페이지 웹앱을 만들어 웹을 앱처럼 만들려다보니 네트워크가 끊겨도 동작, 캐시, 브라우저 메모리 등 여러 요구가 있었고 그래서 프론트의 MVC 프레임워크가 있는데….
  • React는 View에만 집중한다.
  • virtual DOM 방식으로 DOM 조작 성능이 우수하다. react diif algorithm
  • 더 이상 DOM 조작에 집중하지 말라. 이게 렌더링 성능을 악화시킨다. jQuery는 DOM API를 추상화해서 개발 절차를 편리하게 하지만, DOM 조작 자체에 집중하지 않는 시대로 가고 있다. 그래서 jQuery의 시대에 한 걸음 더 가까이 가고 있다.
  • 결국 트렌드는 jQuery와 같이 full package js library를 활용하는 추세에서, 언제든 제거할 수 있는 지금 당장 필요한 작은 polyfill과 utillity 라이브러리 활용으로 변화하고 있다.

flux

  • react를 쓰는데 data가 필요해지면….? 결국 Model(store)이 필요해졌다.
  • 데이터 흐름을 단방향으로 처리. uni-directional data flow 이는 각 레이어가 서로 간의 참조하는 것을 단방향으로 만든다.

react의 의미 있는 장점.

  • google은 자기들이 만들어 놓고 잘 안쓴다.. 하지만 facebook은 React를 쓴다.
  • SPA(싱글 페이지 웹 앱)만을 위한 것이 아니다.
  • vanillaJS(순수 자바스크립트) 방식과의 조화가 가능하다.
  • Isomorphic JavaScript

직접 M,V,C 아키텍쳐를 디자인하고 라이브러리를 만들면 안될까?

  • View의 의존성을 끊고 모듈화를 하자. View 간의 관계를 끊는게 몹시 중요하다.
  • 팀 내 개발자 간의 지식 공유가 안되면 유지하기 어려울 수 있다.
  • flux와 같은 framework가 필요할까? SPA 수준의 웹앱이 필요하면 서라. 그렇지 않다면 굳이 쓰지 마라.
  • pre-compile, js 통합, 품질 확인을 해야한다.

결론

가치를 판단해서 결정하라.

질답

  • sk에서는 아직 나온 것은 없고 만드는 중..
  • naver에서는 웍스에서 곧 나올 예정.
  • 구글의 폴리머는 재사용의 장점이 있고, 프론트의 개발을 쉽게 할 수 있으며, react와 비슷한 면도 있고 표준이 될 가능성이 더 높은 경향이 있지만… 당장은 쓸 수가 없다. 먼 미래의 이야기. 애플이 받아들일까..? 요즘 이야기가 좀 나오는 듯. 같은 프로젝트 내에서 재사용이 좋다.
  • JSX를 안써도 좋다.