SlideShare une entreprise Scribd logo
1  sur  123
Angular2
React
vs
DEVIEW 2016
우리는 왜
이 발표를 하는가?
우리의 관심사
Angular2
React
React’s
Family
Angular2 React
버전 2.1.0 15.3.2
개발사 Google Facebook
깃허브 별수 17k 51k
컨트리뷰터 338 804
HTML 스크립팅 Template JSX
데이터 동기화 Data Binding Virtual DOM + Diff
서버 렌더링 Supported Supported
Angular2 vs React
Overview
Angular2
vs
React
314k
vs
240k
Webpack 최적화 빌드 기준
angular2(AOT) = core + “platform-browser-zone” + core.js
react = react + redux
성능?Angular v2.0.0
React v15.3.1
Vanilla
https://github.com/CoderK/js-framework-benchmark
성능?1. 1000개의 행 생성
2. 10,000개의 행 생성
3. 1,000개의 행 생성
4. 10의 배수인 행 삭제
5. 모든 행 삭제
6. 특정 셀의 데이터 교체
https://github.com/CoderK/js-framework-benchmark
처리속도(기하평균)
2.12 2.00
1.00
0
0.55
1.1
1.65
2.2
2.75
Angular 2.0.0 React v15.2.1 Vanilla
2.67
1.79
1.00
0
0.7
1.4
2.1
2.8
3.5
Angular 2.0.0 React v15.2.1 Vanilla
카테고리 축
제목메모리 사용량
Framework,
왜사용하는 걸까?
생산성?
학습 비용
생태계
신뢰성
개발환경 구축/유지
코드 구현의 용이성
커뮤니케이션
Let's Talk About
학습 비용
생태계
신뢰성
개발환경 구축/유지
코드 구현의 용이성
커뮤니케이션
Table Of Contents
1. 개발환경
2. 언어 생산성
3. 컴포넌트
4. 데이터 동기화
5. 비동기 처리
1.
개발환경
프로젝트 시작시
항상 고민하는 문제
2.
언어 생산성
JavaScript의 영역 확장
애플리케이션의 다양성과 복잡도 증가
대규모 협업시 동적 언어의 한계
Flow?
Facebook이 만든 정적 타입 검사기
React와 별개 프로젝트,
함께 사용할 수 있을 뿐!
Flow?
class Point {
x: number;
y: number;
constructor(x: number, y: number) {
this.x = x;
this.y = y;
}
move(x: number, y: number) {
this.x += x;
this.y += y;
}
copy(): Point {
return new Point(this.x, this.y);
}
}
from http://www.npmdiscover.com/
4% ↓
얼마나 사용하고 있을까?
const todos = [
{id: 1, text: 'Do something', completed: true},
{id: 2, text: 'Do another thing', completed: false}
];
const completedTodos = (todos) => {
return todos.filter(t => t.completed);
};
const result = completedTodos(todos);
// {id: 1, text: 'Do something', completed: true}
console.log(result);
interface Todo {
id: number;
text?: string;
completed: boolean;
}
const todos = [
{id: 1, text: 'Do something', completed: true},
{id: 2, text: 'Do another thing', completed: false}
];
const completeTodos = (todos: Todo[]): Todo[] => {
return todos.filter(t => t.completed);
};
const result = completeTodos(todos);
// {id: 1, text: 'Do something', completed: true},
console.log(result);
interface Todo {
id: number;
text?: string;
completed: boolean;
}
const todos = [
{id: 1, text: 'Do something', completed: true},
{id: 2, text: 'Do another thing', completed: false}
];
const completeTodos = (todos: Todo[]): Todo[] => {
return todos.filter(t => t.completed);
};
const result = completeTodos(todos);
// {id: 1, text: 'Do something', completed: true},
console.log(result);
외부 모듈이 타입을
제공하지 않는다
면?1. 타입 정의 파일이 있는지 검색한다
1. 타입 정의 파일이 있는지 검색한다
2. 없으면 네가 만든다
외부 모듈이 타입을
제공하지 않는다
면?
1. 타입 정의 파일이 있는지 검색한다
2. 없으면 네가 만든다
3. 귀찮으면 Any로 선언하거나 타입 없이 코딩한다
외부 모듈이 타입을
제공하지 않는다
면?
비용> 소득
따져봐야 할 일
Angular2는
왜 TypeScript를
강요하나요?
“
Angular2는,
TypeScript라서 싫어요
”
트랜스컴파일 언어?
새로운 언어?
Metadata
Metadata
Annotations
Optional
Type
Optional Type Types
언어 생산성 향
상
Angular2의 고민
웹표준 지향
ES6
ES
5
classes
modules
ES2015의 생산성 극대화
TypeScript 1.5+
언어를 만들자, AtScript!!!
Annotations
Types
ES6
ES
5
Metadata
Optional Type
TypeScript 사용에 따른
비용 >? 소득
당근, 따져보자!
TypeScript
function sum(value: Array<number>): number {
return value.reduce( (sum, v) => sum + v),0);
}
JavaScript
function sum(value) {
if(Array.isArray(value)) {
return value.reduce((sum, v) => {
return parseInt(sum + v), 0);
});
} else {
return 0;
}
}
TypeScript
= ES.Next
= JavaScript의 SuperSet
JavaScript 개발자라면
선투자
새로운 언어, 학습비용?
3.
컴포넌트
하나의 독립된 기능을
수행하는 최소 단위 UI
Angular2와 React 모두 컴포넌트 설계를 지향
컴포넌트 = HTML + JS +
CSS
@Component({
selector: 'app',
templateUrl: 'app.component.html',
styleUrls: ['app.component.css'],
encapsulation: ViewEncapsulation.Emulated
})
export class AppComponent {
constructor() {
}
}
HTML
CSS
JS
Angular2’s Component
React의
컴포넌트는 반쪽짜
리
<div class="layout">
<div class="left">{{value1}}</div>
<div class="right">{{value2}}</div>
<div class="footer">{{value3}}</div>
</div>
기본으로 제공하지 않는 CSS 캡슐화
Compon
ent
더 정이 안 가는 이유는
JSX in JS
render() {
return (
<section className="main">
<ul className="todo-list">
{
this.getItems()
.map(item => {
return (
<TodoItem key={ item.id }/>
);
})
}
</ul>
</section>
);
}
마크업 개발자와
협업 곤란
<div>
<div className="active">
<input defaultValue="value"/>
</div>
<footer></footer>
<div>
React
<div class="active">
<input value="value"/>
</div>
<footer></footer>
HTML과 같은 듯, 다른 문법
Angular2
표준 HTML + Extend 새로운 언어? JSX
인정!
그런데 잠깐,
템플릿은
협업과 무관한가?
<h1>Users</h1>
<div>Loading users data</div>
<div>
<button type="button">Load More Users</button>
<a href="#">Create user</a>
<ul class="users-list">
<li>
<a href="#">
<img src='http://sample.blahblah.blah/pic1.jpg'/>
</a>
<div class="actions">
<a href="#">edit</a>
</div>
</li>
<li>
<a href="#">
<img src='http://sample.blahblah.blah/pic1.jpg'/>
</a>
<div class="actions">
<a href="#">edit</a>
</div>
</li>
<li>
<a href="#">
<img src='http://sample.blahblah.blah/pic1.jpg'/>
</a>
<div class="actions">
<a href="#">edit</a>
</div>
</li>
</ul>
</div>
<h1>Users</h1>
<div *ngIf="loading">Loading users data</div>
<div *ngIf="!loading">
<button type="button"
loading-btn
[loadingText]="'Loading more...'"
[loadingMore]="userService.loading"
(sampleCustomEvent)="eventHandler($event)"
(click)="userService.getMoreUsers()">Load More Users</button>
<a [routerLink]="['./User-create']">Create user</a>
<ul class="users-list" set-active>
<li *ngFor="#user of users">
<a [routerLink]="['./User-details', { username: user.username }]">
<img [src]="user.picture.medium" alt="{{ user.username }}'s picture" />
{{ user.name.last }}, {{ user.name.first }}</a>
<div class="actions">
<a [routerLink]="['./User-edit', { username: user.username }]">edit</a>
</div>
</li>
</ul>
</div>
<h1>Users</h1>
<div *ngIf="loading">Loading users data</div>
<div *ngIf="!loading">
<button type="button"
loading-btn
[loadingText]="'Loading more...'"
[loadingMore]="userService.loading"
(sampleCustomEvent)="eventHandler($event)"
(click)="userService.getMoreUsers()">Load More Users</button>
<a [routerLink]="['./User-create']">Create user</a>
<ul class="users-list" set-active>
<li *ngFor="#user of users">
<a [routerLink]="['./User-details', { username: user.username }]">
<img [src]="user.picture.medium" alt="{{ user.username }}'s picture" />
{{ user.name.last }}, {{ user.name.first }}</a>
<div class="actions">
<a [routerLink]="['./User-edit', { username: user.username }]">edit</a>
</div>
</li>
</ul>
</div>
이미 순수하지 못한 HTML
Just
Syntactic SugarNot HTML, Not Template
render() {
return React.createElement(
"div",
null,
"Hello ",
this.props.name
);
}
render() {
return <div>Hello {this.props.name}</div>;
}
render() {
return (
<section className="main">
<ul className="todo-list">
{
this.getItems()
.map(item => {
debugger;
return (
<TodoItem key={ item.id }
text={ item.text }
id={ item.id }
/>
);
})
}
</ul>
</section>
);
}
JSX = 구조 + 기능
JSX in JavaScript는
구조와 기능을 자연스럽게 표현
기능 확장,
의존 컴포넌트 주입(HOF)
export const Sortable = (props) => {
return (
<Sortable>
{ props.children }
</Sortable>
)
}
// SortableBox
<Sortable><Box></Sortable>
// SortableTriangle
<Sortable><Triangle></Sortable>
기능 확장,
의존 컴포넌트 주입(HOF)
export const Sortable = (props) => {
return (
<Sortable>
{ props.children }
</Sortable>
)
}
// SortableBox
<Sortable><Box></Sortable>
// SortableTriangle
<Sortable><Triangle></Sortable>
export const Sortable = (props) => {
return (
<Sortable>
{ props.children }
</Sortable>
)
}
// SortableBox
<Sortable><Box></Sortable>
// SortableTriangle
<Sortable><Triangle></Sortable>
기능 확장,
의존 컴포넌트 주입(HOF)
High Order Componen
<Sortable>
<Box></Box>
</Sortable>
compose(sortable, box);
new Sortable(new Box());
둘일 때는 불리,
하지만 혼자라면?
4.
데이터 동기화
뷰(View)와 모델(Model)의 분리,
데이터 동기화 문제 등장
UI 개발 프레임워크가 책임지는 핵심
Angular’s
Data Binding
DOM View Model
Angular’s
Data Binding
DOM View Model
Two Way
Data Binding
DOM View Model
Two Way
Data Binding
DOM View Model
DOM
View
Model
DOM
View Model
DOM
View Model
DOM
View Model
DOM
View
DOM
View
DOM
View
DOM
View
Mode
l
Mode
l
Mode
l
Mode
l
View
View
View
DOM
Mode
l
DOM
DOM
Let’s Reactive
DOM View
Let’s Reactive
DOM View
Let’s Reactive
Virtual DOM + Reconciliation
DOM
Virtual
DOM
Let’s Reactive
Virtual DOM + Reconciliation
DOM
Virtual
DOM
Virtual
DOM
Let’s Reactive
Virtual DOM + Reconciliation
DOM
Virtual
DOM
Virtual
DOM
Diff
Virtual DOM
Virtual DOM
변경 전 변경 후
변경 전 변경 후
DOM
변경 전
변경 후
Patch
양방향 데이터 바인딩이
복잡도를 증가시킨다?
class MyForm extends React.Component {
constructor() {
this.state = {value: 'Hello!'};
this.handleChange = this.handleChange.bind(this);
this.handleClick = this.handleClick.bind(this);
}
handleChange(event) {
this.setState({value: event.target.value});
}
handleClick() {
this.setState({value: 'changed!'});
}
render() {
return (
<div>
<input type="text" value={this.state.value} onChange={this.handleChange} />
<button onClick={this.handleClick} >change</button>
</div>
);
}
}
React’s example
setState로 데이터 변경!
@Component({
selector: 'form',
template: [`
<div>
<input type="text" [(ngModel)]=“state.value”/>
<button (click)=“handleClick()">change</button>
</div>
`
})
class MyFrom() {
state = { value: 'Hello'};
constructor() {}
handleClick() {
this.state.value = 'changed';
}
}
데이터 바인딩은 Simple
Angular2’s example
React, 짱먹어라
앞으로는 무분별하게
양방향 데이터 동기
화를
사용하지 않겠습니다.
<h1>{{data}}</h1>
Angular1
DOM
Mode
lView
2way-binding
Angular2
DOM
Mode
lView
1way-binding
<h1>{{data}}</h1>
!!!!CD
CD CD
CD
CD
CD
CD
CD
CD
CD
CD
Change Detector DOM
Angular2
CD
CD CD
CD
CD
CD
CD
CD
CD
CD
CD
CD
CD
$timeout(function() {
// something
}, 1000);
$http({
method: 'GET',
url: '/someUrl'
});
$scope.$apply();
비동기 액션이 끝나는 시점을 알려
주면
데이터 동기화 수행
ZoneJavaScript의 실행영역(Excute context)
실행영역에서 발생하는 작업을
Profile
Zone.current.fork({
onInvokeTask: (…): any => {
try {
this.onEnter();
return delegate.invokeTask(…);
} finally {
this.onLeave();
}
}
}).run(main);
데이터 동기화
시점
timeout(function() {
// something
}, 1000);
somethingHttp({
method: 'GET',
url: '/someUrl'
});
model.value = "change!!!";
Angular1의 데이터 바인
딩
+ React 데이터 플로우의 심
플함
+ Zone을 이용한 사용성 개
선
데이터 바인딩?
Virtual DOM diff?
DOM이 아닌,
모델에 초점
React
DOM View Model
DOM View Model
Framework
담당
setState, action
명시적 호출
Angular2
DOM View Model
DOM View Model
Framework
담당
5.
비동기 처리
인터랙션 이벤트, 애니메이션, XMLHttpRequest,
멀티미디어 자원(이미지, 동영상…) 로딩,
WebWorker, WebRTC, WebSocket…
핑크빛 열애설
Angular2랑 RxJS…?
import React from 'react';
import Async from 'react-async';
import Rx from 'rx';
function defineXHRObservable(url) {
return {
id: url,
start() {
return Rx.fromPromise(fetch(url))
}
}
}
function MyComponentObservables(props) {
return {
user: defineXHRObservable(`/api/user?user${props.userID}`)
}
}
@Async(MyComponentObservables)
class MyComponent extends React.Component {
render() {
let {user} = this.props
...
}
}
callback,
promise,
generator,
async/await
Observable
Subscriber
Message
Observable
Subscribe
Store
Component
State
Subscriber
SubjectMessage
Subscriber
Subject
Store
Action
Component
Subscriber
Subject
State
Action
Store
Component
Subscriber
Subject
Store
Component
http://www.slideshare.net/jayphelps/rxjs-redux-react-amazing
프레임워크 구현에
잘녹여진
RxJS
Zone.current.fork({
onInvokeTask: (…): any => {
try {
this.onEnter();
return delegate.invokeTask(…);
} finally {
this.onLeave();
}
}
}).run(main);
데이터 동기화
시점
기억나시죠?
class NgZone {
private _onMicrotaskEmpty: EventEmitter;
private _onStable: EventEmitter;
private onLeave() { this.checkStable(); }
private checkStable() {
try {
this._onMicrotaskEmpty.emit(null);
} finally {
this._onStable.emit(null)
}
}
}
class EventEmitter extends Subject<T> {
emit(value) { super.next(value); }
}
Rx.Subject
산발적인 이벤트를
스트림(Stream)으
로
CD
CD CD
CD
CD
CD
CD
CD
CD
CD
CD
Change Detector
CD
CD CD
CD
CD
CD
CD
CD
CD
CD
CD
기억나시죠?
CD
CD CD
CD
CD
CD
CD
CD
CD
CD
CD
Change Detector
Observable
+ OnPush ChangeDetectionStrategy
CD
CD
CD
CD
개발자 입장에서도
RxJS를 쉽게 사용
// HTTP
this.jsonp.get('http://url?callback=CALLBACK')
.map(res => console.log(res.json()));
// FORM
var term = new FormControl();
term.valueChanges
.debounceTime(400)
.distinctUntilChanged()
.subscribe(v => console.log(v.keyCode);
Angular2의
HTTP, FORM은 RxJS를
지원
// Service
this.service.getSpreadsheet()
.filter(x => !!x)
.subscribe(v => {
this.spreadsheet = v;
});
}
서비스와 컴포넌트를 push 방식으로 연결
느슨한 결합
RxJS
정말 좋은가?
그래서,
당신이 선택해야 할
프레임워크는?
최소 기능 기본 개발자의 선택
개발자의 선택최소 기능
데이타 동기화
컴포넌트
…
코딩 컨벤션
Application
Infra
…
찬욱의 생각
프레임워크 쓸거라면…
문제의 솔루션…
유연성?
구글?
훈민의 생각
선택은 개발자가 해야할 일
All-In-One, 글쎄?
구글?
감사합니다

Contenu connexe

Tendances

20170813 django api server unit test and remote debugging
20170813 django api server unit test and remote debugging20170813 django api server unit test and remote debugging
20170813 django api server unit test and remote debuggingJongwon Han
 
웹 Front-End 실무 이야기
웹 Front-End 실무 이야기웹 Front-End 실무 이야기
웹 Front-End 실무 이야기JinKwon Lee
 
Vue SSR vs Prerender
Vue SSR vs PrerenderVue SSR vs Prerender
Vue SSR vs PrerenderChangwan Jun
 
Isomorphicspring Isomorphic - spring web seminar 2015
Isomorphicspring Isomorphic - spring web seminar 2015Isomorphicspring Isomorphic - spring web seminar 2015
Isomorphicspring Isomorphic - spring web seminar 2015sung yong jung
 
Mean 스택을 사용한 IoT 개발
Mean 스택을 사용한 IoT 개발Mean 스택을 사용한 IoT 개발
Mean 스택을 사용한 IoT 개발Jay Park
 
Electron mainprocess
Electron mainprocessElectron mainprocess
Electron mainprocessDaehwan Lee
 
[ Pycon Korea 2017 ] Infrastructure as Code를위한 Ansible 활용
[ Pycon Korea 2017 ] Infrastructure as Code를위한 Ansible 활용[ Pycon Korea 2017 ] Infrastructure as Code를위한 Ansible 활용
[ Pycon Korea 2017 ] Infrastructure as Code를위한 Ansible 활용Jihyung Song
 
React 튜토리얼 1차시
React 튜토리얼 1차시React 튜토리얼 1차시
React 튜토리얼 1차시태현 김
 
[231]나는서버를썰터이니너는개발만하여라 양지욱
[231]나는서버를썰터이니너는개발만하여라 양지욱[231]나는서버를썰터이니너는개발만하여라 양지욱
[231]나는서버를썰터이니너는개발만하여라 양지욱NAVER D2
 
React 애플리케이션 아키텍처 - 아무도 알려주지 않아서 혼자서 삽질했다.
React 애플리케이션 아키텍처 - 아무도 알려주지 않아서 혼자서 삽질했다.React 애플리케이션 아키텍처 - 아무도 알려주지 않아서 혼자서 삽질했다.
React 애플리케이션 아키텍처 - 아무도 알려주지 않아서 혼자서 삽질했다.병대 손
 
[141] react everywhere
[141] react everywhere[141] react everywhere
[141] react everywhereNAVER D2
 
React Native를 사용한
 초간단 커뮤니티 앱 제작
React Native를 사용한
 초간단 커뮤니티 앱 제작React Native를 사용한
 초간단 커뮤니티 앱 제작
React Native를 사용한
 초간단 커뮤니티 앱 제작Taegon Kim
 
김찬웅_그룹웨어에 새 에너지를_NDC15
김찬웅_그룹웨어에 새 에너지를_NDC15김찬웅_그룹웨어에 새 에너지를_NDC15
김찬웅_그룹웨어에 새 에너지를_NDC15Chanwoong Kim
 
[D2 CAMPUS] tech meet up(Back-end) - 교내 웹서비스 개발 일지 (박은찬님)
[D2 CAMPUS] tech meet up(Back-end) - 교내 웹서비스 개발 일지 (박은찬님)[D2 CAMPUS] tech meet up(Back-end) - 교내 웹서비스 개발 일지 (박은찬님)
[D2 CAMPUS] tech meet up(Back-end) - 교내 웹서비스 개발 일지 (박은찬님)NAVER D2
 
Universal Rendering
Universal RenderingUniversal Rendering
Universal RenderingTaegon Kim
 
웹-프론트엔드 프레임워크를 고르기 위한 팁
웹-프론트엔드 프레임워크를 고르기 위한 팁웹-프론트엔드 프레임워크를 고르기 위한 팁
웹-프론트엔드 프레임워크를 고르기 위한 팁WebFrameworks
 
React 튜토리얼 2차시
React 튜토리얼 2차시React 튜토리얼 2차시
React 튜토리얼 2차시태현 김
 
파이콘 2017 그만퇴근합시다_이지호
파이콘 2017 그만퇴근합시다_이지호파이콘 2017 그만퇴근합시다_이지호
파이콘 2017 그만퇴근합시다_이지호Jiho Lee
 

Tendances (20)

20170813 django api server unit test and remote debugging
20170813 django api server unit test and remote debugging20170813 django api server unit test and remote debugging
20170813 django api server unit test and remote debugging
 
웹 Front-End 실무 이야기
웹 Front-End 실무 이야기웹 Front-End 실무 이야기
웹 Front-End 실무 이야기
 
Vue SSR vs Prerender
Vue SSR vs PrerenderVue SSR vs Prerender
Vue SSR vs Prerender
 
Isomorphicspring Isomorphic - spring web seminar 2015
Isomorphicspring Isomorphic - spring web seminar 2015Isomorphicspring Isomorphic - spring web seminar 2015
Isomorphicspring Isomorphic - spring web seminar 2015
 
Mean 스택을 사용한 IoT 개발
Mean 스택을 사용한 IoT 개발Mean 스택을 사용한 IoT 개발
Mean 스택을 사용한 IoT 개발
 
Electron mainprocess
Electron mainprocessElectron mainprocess
Electron mainprocess
 
[ Pycon Korea 2017 ] Infrastructure as Code를위한 Ansible 활용
[ Pycon Korea 2017 ] Infrastructure as Code를위한 Ansible 활용[ Pycon Korea 2017 ] Infrastructure as Code를위한 Ansible 활용
[ Pycon Korea 2017 ] Infrastructure as Code를위한 Ansible 활용
 
iOS9 소개
iOS9 소개iOS9 소개
iOS9 소개
 
React 튜토리얼 1차시
React 튜토리얼 1차시React 튜토리얼 1차시
React 튜토리얼 1차시
 
[231]나는서버를썰터이니너는개발만하여라 양지욱
[231]나는서버를썰터이니너는개발만하여라 양지욱[231]나는서버를썰터이니너는개발만하여라 양지욱
[231]나는서버를썰터이니너는개발만하여라 양지욱
 
React 애플리케이션 아키텍처 - 아무도 알려주지 않아서 혼자서 삽질했다.
React 애플리케이션 아키텍처 - 아무도 알려주지 않아서 혼자서 삽질했다.React 애플리케이션 아키텍처 - 아무도 알려주지 않아서 혼자서 삽질했다.
React 애플리케이션 아키텍처 - 아무도 알려주지 않아서 혼자서 삽질했다.
 
[141] react everywhere
[141] react everywhere[141] react everywhere
[141] react everywhere
 
React Native를 사용한
 초간단 커뮤니티 앱 제작
React Native를 사용한
 초간단 커뮤니티 앱 제작React Native를 사용한
 초간단 커뮤니티 앱 제작
React Native를 사용한
 초간단 커뮤니티 앱 제작
 
김찬웅_그룹웨어에 새 에너지를_NDC15
김찬웅_그룹웨어에 새 에너지를_NDC15김찬웅_그룹웨어에 새 에너지를_NDC15
김찬웅_그룹웨어에 새 에너지를_NDC15
 
[D2 CAMPUS] tech meet up(Back-end) - 교내 웹서비스 개발 일지 (박은찬님)
[D2 CAMPUS] tech meet up(Back-end) - 교내 웹서비스 개발 일지 (박은찬님)[D2 CAMPUS] tech meet up(Back-end) - 교내 웹서비스 개발 일지 (박은찬님)
[D2 CAMPUS] tech meet up(Back-end) - 교내 웹서비스 개발 일지 (박은찬님)
 
Universal Rendering
Universal RenderingUniversal Rendering
Universal Rendering
 
웹-프론트엔드 프레임워크를 고르기 위한 팁
웹-프론트엔드 프레임워크를 고르기 위한 팁웹-프론트엔드 프레임워크를 고르기 위한 팁
웹-프론트엔드 프레임워크를 고르기 위한 팁
 
React 튜토리얼 2차시
React 튜토리얼 2차시React 튜토리얼 2차시
React 튜토리얼 2차시
 
Modern PHP
Modern PHPModern PHP
Modern PHP
 
파이콘 2017 그만퇴근합시다_이지호
파이콘 2017 그만퇴근합시다_이지호파이콘 2017 그만퇴근합시다_이지호
파이콘 2017 그만퇴근합시다_이지호
 

Similaire à [114]angularvs react 김훈민손찬욱

AngularJS 2, version 1 and ReactJS
AngularJS 2, version 1 and ReactJSAngularJS 2, version 1 and ReactJS
AngularJS 2, version 1 and ReactJSKenneth Ceyer
 
[NDC17] Unreal.js - 자바스크립트로 쉽고 빠른 UE4 개발하기
[NDC17] Unreal.js - 자바스크립트로 쉽고 빠른 UE4 개발하기[NDC17] Unreal.js - 자바스크립트로 쉽고 빠른 UE4 개발하기
[NDC17] Unreal.js - 자바스크립트로 쉽고 빠른 UE4 개발하기현철 조
 
ReactJS | 서버와 클라이어트에서 동시에 사용하는
ReactJS | 서버와 클라이어트에서 동시에 사용하는ReactJS | 서버와 클라이어트에서 동시에 사용하는
ReactJS | 서버와 클라이어트에서 동시에 사용하는Taegon Kim
 
ReactJS로 시작하는 멀티플랫폼 개발하기
ReactJS로 시작하는 멀티플랫폼 개발하기ReactJS로 시작하는 멀티플랫폼 개발하기
ReactJS로 시작하는 멀티플랫폼 개발하기Taegon Kim
 
React를 이용하여 멀티플랫폼에서 개발하기
React를 이용하여 멀티플랫폼에서 개발하기React를 이용하여 멀티플랫폼에서 개발하기
React를 이용하여 멀티플랫폼에서 개발하기WebFrameworks
 
Domain Specific Languages With Groovy
Domain Specific Languages With GroovyDomain Specific Languages With Groovy
Domain Specific Languages With GroovyTommy C. Kang
 
Facebook은 React를 왜 만들었을까?
Facebook은 React를 왜 만들었을까? Facebook은 React를 왜 만들었을까?
Facebook은 React를 왜 만들었을까? Kim Hunmin
 
Angular는 사실 어렵지 않습니다.
Angular는 사실 어렵지 않습니다.Angular는 사실 어렵지 않습니다.
Angular는 사실 어렵지 않습니다.장현 한
 
Secrets of the JavaScript Ninja - Chapter 12. DOM modification
Secrets of the JavaScript Ninja - Chapter 12. DOM modificationSecrets of the JavaScript Ninja - Chapter 12. DOM modification
Secrets of the JavaScript Ninja - Chapter 12. DOM modificationHyuncheol Jeon
 
20201121 코드 삼분지계
20201121 코드 삼분지계20201121 코드 삼분지계
20201121 코드 삼분지계Chiwon Song
 
Django를 Django답게, Django로 뉴스 사이트 만들기
Django를 Django답게, Django로 뉴스 사이트 만들기Django를 Django답게, Django로 뉴스 사이트 만들기
Django를 Django답게, Django로 뉴스 사이트 만들기Kyoung Up Jung
 
자바 웹 개발 시작하기 (9주차 : 프로젝트 구현 – 추가적인 뷰)
자바 웹 개발 시작하기 (9주차 : 프로젝트 구현 – 추가적인 뷰)자바 웹 개발 시작하기 (9주차 : 프로젝트 구현 – 추가적인 뷰)
자바 웹 개발 시작하기 (9주차 : 프로젝트 구현 – 추가적인 뷰)DK Lee
 
안드로이드 빌드: 설탕없는 세계
안드로이드 빌드: 설탕없는 세계안드로이드 빌드: 설탕없는 세계
안드로이드 빌드: 설탕없는 세계Leonardo YongUk Kim
 
NDC11_김성익_슈퍼클래스
NDC11_김성익_슈퍼클래스NDC11_김성익_슈퍼클래스
NDC11_김성익_슈퍼클래스Sungik Kim
 
Android Native Module 안정적으로 개발하기
Android Native Module 안정적으로 개발하기Android Native Module 안정적으로 개발하기
Android Native Module 안정적으로 개발하기hanbeom Park
 
자바스크립트 프레임워크 살펴보기
자바스크립트 프레임워크 살펴보기자바스크립트 프레임워크 살펴보기
자바스크립트 프레임워크 살펴보기Jeado Ko
 

Similaire à [114]angularvs react 김훈민손찬욱 (20)

AngularJS 2, version 1 and ReactJS
AngularJS 2, version 1 and ReactJSAngularJS 2, version 1 and ReactJS
AngularJS 2, version 1 and ReactJS
 
[NDC17] Unreal.js - 자바스크립트로 쉽고 빠른 UE4 개발하기
[NDC17] Unreal.js - 자바스크립트로 쉽고 빠른 UE4 개발하기[NDC17] Unreal.js - 자바스크립트로 쉽고 빠른 UE4 개발하기
[NDC17] Unreal.js - 자바스크립트로 쉽고 빠른 UE4 개발하기
 
ReactJS | 서버와 클라이어트에서 동시에 사용하는
ReactJS | 서버와 클라이어트에서 동시에 사용하는ReactJS | 서버와 클라이어트에서 동시에 사용하는
ReactJS | 서버와 클라이어트에서 동시에 사용하는
 
[Codelab 2017] ReactJS 기초
[Codelab 2017] ReactJS 기초[Codelab 2017] ReactJS 기초
[Codelab 2017] ReactJS 기초
 
ReactJS로 시작하는 멀티플랫폼 개발하기
ReactJS로 시작하는 멀티플랫폼 개발하기ReactJS로 시작하는 멀티플랫폼 개발하기
ReactJS로 시작하는 멀티플랫폼 개발하기
 
React를 이용하여 멀티플랫폼에서 개발하기
React를 이용하여 멀티플랫폼에서 개발하기React를 이용하여 멀티플랫폼에서 개발하기
React를 이용하여 멀티플랫폼에서 개발하기
 
react-ko.pdf
react-ko.pdfreact-ko.pdf
react-ko.pdf
 
Domain Specific Languages With Groovy
Domain Specific Languages With GroovyDomain Specific Languages With Groovy
Domain Specific Languages With Groovy
 
Facebook은 React를 왜 만들었을까?
Facebook은 React를 왜 만들었을까? Facebook은 React를 왜 만들었을까?
Facebook은 React를 왜 만들었을까?
 
Angular는 사실 어렵지 않습니다.
Angular는 사실 어렵지 않습니다.Angular는 사실 어렵지 않습니다.
Angular는 사실 어렵지 않습니다.
 
Secrets of the JavaScript Ninja - Chapter 12. DOM modification
Secrets of the JavaScript Ninja - Chapter 12. DOM modificationSecrets of the JavaScript Ninja - Chapter 12. DOM modification
Secrets of the JavaScript Ninja - Chapter 12. DOM modification
 
20201121 코드 삼분지계
20201121 코드 삼분지계20201121 코드 삼분지계
20201121 코드 삼분지계
 
Django를 Django답게, Django로 뉴스 사이트 만들기
Django를 Django답게, Django로 뉴스 사이트 만들기Django를 Django답게, Django로 뉴스 사이트 만들기
Django를 Django답게, Django로 뉴스 사이트 만들기
 
자바 웹 개발 시작하기 (9주차 : 프로젝트 구현 – 추가적인 뷰)
자바 웹 개발 시작하기 (9주차 : 프로젝트 구현 – 추가적인 뷰)자바 웹 개발 시작하기 (9주차 : 프로젝트 구현 – 추가적인 뷰)
자바 웹 개발 시작하기 (9주차 : 프로젝트 구현 – 추가적인 뷰)
 
Scala for play
Scala for playScala for play
Scala for play
 
안드로이드 빌드: 설탕없는 세계
안드로이드 빌드: 설탕없는 세계안드로이드 빌드: 설탕없는 세계
안드로이드 빌드: 설탕없는 세계
 
NDC11_김성익_슈퍼클래스
NDC11_김성익_슈퍼클래스NDC11_김성익_슈퍼클래스
NDC11_김성익_슈퍼클래스
 
Android Native Module 안정적으로 개발하기
Android Native Module 안정적으로 개발하기Android Native Module 안정적으로 개발하기
Android Native Module 안정적으로 개발하기
 
자바스크립트 프레임워크 살펴보기
자바스크립트 프레임워크 살펴보기자바스크립트 프레임워크 살펴보기
자바스크립트 프레임워크 살펴보기
 
Linq
LinqLinq
Linq
 

Plus de NAVER D2

[211] 인공지능이 인공지능 챗봇을 만든다
[211] 인공지능이 인공지능 챗봇을 만든다[211] 인공지능이 인공지능 챗봇을 만든다
[211] 인공지능이 인공지능 챗봇을 만든다NAVER D2
 
[233] 대형 컨테이너 클러스터에서의 고가용성 Network Load Balancing: Maglev Hashing Scheduler i...
[233] 대형 컨테이너 클러스터에서의 고가용성 Network Load Balancing: Maglev Hashing Scheduler i...[233] 대형 컨테이너 클러스터에서의 고가용성 Network Load Balancing: Maglev Hashing Scheduler i...
[233] 대형 컨테이너 클러스터에서의 고가용성 Network Load Balancing: Maglev Hashing Scheduler i...NAVER D2
 
[215] Druid로 쉽고 빠르게 데이터 분석하기
[215] Druid로 쉽고 빠르게 데이터 분석하기[215] Druid로 쉽고 빠르게 데이터 분석하기
[215] Druid로 쉽고 빠르게 데이터 분석하기NAVER D2
 
[245]Papago Internals: 모델분석과 응용기술 개발
[245]Papago Internals: 모델분석과 응용기술 개발[245]Papago Internals: 모델분석과 응용기술 개발
[245]Papago Internals: 모델분석과 응용기술 개발NAVER D2
 
[236] 스트림 저장소 최적화 이야기: 아파치 드루이드로부터 얻은 교훈
[236] 스트림 저장소 최적화 이야기: 아파치 드루이드로부터 얻은 교훈[236] 스트림 저장소 최적화 이야기: 아파치 드루이드로부터 얻은 교훈
[236] 스트림 저장소 최적화 이야기: 아파치 드루이드로부터 얻은 교훈NAVER D2
 
[235]Wikipedia-scale Q&A
[235]Wikipedia-scale Q&A[235]Wikipedia-scale Q&A
[235]Wikipedia-scale Q&ANAVER D2
 
[244]로봇이 현실 세계에 대해 학습하도록 만들기
[244]로봇이 현실 세계에 대해 학습하도록 만들기[244]로봇이 현실 세계에 대해 학습하도록 만들기
[244]로봇이 현실 세계에 대해 학습하도록 만들기NAVER D2
 
[243] Deep Learning to help student’s Deep Learning
[243] Deep Learning to help student’s Deep Learning[243] Deep Learning to help student’s Deep Learning
[243] Deep Learning to help student’s Deep LearningNAVER D2
 
[234]Fast & Accurate Data Annotation Pipeline for AI applications
[234]Fast & Accurate Data Annotation Pipeline for AI applications[234]Fast & Accurate Data Annotation Pipeline for AI applications
[234]Fast & Accurate Data Annotation Pipeline for AI applicationsNAVER D2
 
Old version: [233]대형 컨테이너 클러스터에서의 고가용성 Network Load Balancing
Old version: [233]대형 컨테이너 클러스터에서의 고가용성 Network Load BalancingOld version: [233]대형 컨테이너 클러스터에서의 고가용성 Network Load Balancing
Old version: [233]대형 컨테이너 클러스터에서의 고가용성 Network Load BalancingNAVER D2
 
[226]NAVER 광고 deep click prediction: 모델링부터 서빙까지
[226]NAVER 광고 deep click prediction: 모델링부터 서빙까지[226]NAVER 광고 deep click prediction: 모델링부터 서빙까지
[226]NAVER 광고 deep click prediction: 모델링부터 서빙까지NAVER D2
 
[225]NSML: 머신러닝 플랫폼 서비스하기 & 모델 튜닝 자동화하기
[225]NSML: 머신러닝 플랫폼 서비스하기 & 모델 튜닝 자동화하기[225]NSML: 머신러닝 플랫폼 서비스하기 & 모델 튜닝 자동화하기
[225]NSML: 머신러닝 플랫폼 서비스하기 & 모델 튜닝 자동화하기NAVER D2
 
[224]네이버 검색과 개인화
[224]네이버 검색과 개인화[224]네이버 검색과 개인화
[224]네이버 검색과 개인화NAVER D2
 
[216]Search Reliability Engineering (부제: 지진에도 흔들리지 않는 네이버 검색시스템)
[216]Search Reliability Engineering (부제: 지진에도 흔들리지 않는 네이버 검색시스템)[216]Search Reliability Engineering (부제: 지진에도 흔들리지 않는 네이버 검색시스템)
[216]Search Reliability Engineering (부제: 지진에도 흔들리지 않는 네이버 검색시스템)NAVER D2
 
[214] Ai Serving Platform: 하루 수 억 건의 인퍼런스를 처리하기 위한 고군분투기
[214] Ai Serving Platform: 하루 수 억 건의 인퍼런스를 처리하기 위한 고군분투기[214] Ai Serving Platform: 하루 수 억 건의 인퍼런스를 처리하기 위한 고군분투기
[214] Ai Serving Platform: 하루 수 억 건의 인퍼런스를 처리하기 위한 고군분투기NAVER D2
 
[213] Fashion Visual Search
[213] Fashion Visual Search[213] Fashion Visual Search
[213] Fashion Visual SearchNAVER D2
 
[232] TensorRT를 활용한 딥러닝 Inference 최적화
[232] TensorRT를 활용한 딥러닝 Inference 최적화[232] TensorRT를 활용한 딥러닝 Inference 최적화
[232] TensorRT를 활용한 딥러닝 Inference 최적화NAVER D2
 
[242]컴퓨터 비전을 이용한 실내 지도 자동 업데이트 방법: 딥러닝을 통한 POI 변화 탐지
[242]컴퓨터 비전을 이용한 실내 지도 자동 업데이트 방법: 딥러닝을 통한 POI 변화 탐지[242]컴퓨터 비전을 이용한 실내 지도 자동 업데이트 방법: 딥러닝을 통한 POI 변화 탐지
[242]컴퓨터 비전을 이용한 실내 지도 자동 업데이트 방법: 딥러닝을 통한 POI 변화 탐지NAVER D2
 
[212]C3, 데이터 처리에서 서빙까지 가능한 하둡 클러스터
[212]C3, 데이터 처리에서 서빙까지 가능한 하둡 클러스터[212]C3, 데이터 처리에서 서빙까지 가능한 하둡 클러스터
[212]C3, 데이터 처리에서 서빙까지 가능한 하둡 클러스터NAVER D2
 
[223]기계독해 QA: 검색인가, NLP인가?
[223]기계독해 QA: 검색인가, NLP인가?[223]기계독해 QA: 검색인가, NLP인가?
[223]기계독해 QA: 검색인가, NLP인가?NAVER D2
 

Plus de NAVER D2 (20)

[211] 인공지능이 인공지능 챗봇을 만든다
[211] 인공지능이 인공지능 챗봇을 만든다[211] 인공지능이 인공지능 챗봇을 만든다
[211] 인공지능이 인공지능 챗봇을 만든다
 
[233] 대형 컨테이너 클러스터에서의 고가용성 Network Load Balancing: Maglev Hashing Scheduler i...
[233] 대형 컨테이너 클러스터에서의 고가용성 Network Load Balancing: Maglev Hashing Scheduler i...[233] 대형 컨테이너 클러스터에서의 고가용성 Network Load Balancing: Maglev Hashing Scheduler i...
[233] 대형 컨테이너 클러스터에서의 고가용성 Network Load Balancing: Maglev Hashing Scheduler i...
 
[215] Druid로 쉽고 빠르게 데이터 분석하기
[215] Druid로 쉽고 빠르게 데이터 분석하기[215] Druid로 쉽고 빠르게 데이터 분석하기
[215] Druid로 쉽고 빠르게 데이터 분석하기
 
[245]Papago Internals: 모델분석과 응용기술 개발
[245]Papago Internals: 모델분석과 응용기술 개발[245]Papago Internals: 모델분석과 응용기술 개발
[245]Papago Internals: 모델분석과 응용기술 개발
 
[236] 스트림 저장소 최적화 이야기: 아파치 드루이드로부터 얻은 교훈
[236] 스트림 저장소 최적화 이야기: 아파치 드루이드로부터 얻은 교훈[236] 스트림 저장소 최적화 이야기: 아파치 드루이드로부터 얻은 교훈
[236] 스트림 저장소 최적화 이야기: 아파치 드루이드로부터 얻은 교훈
 
[235]Wikipedia-scale Q&A
[235]Wikipedia-scale Q&A[235]Wikipedia-scale Q&A
[235]Wikipedia-scale Q&A
 
[244]로봇이 현실 세계에 대해 학습하도록 만들기
[244]로봇이 현실 세계에 대해 학습하도록 만들기[244]로봇이 현실 세계에 대해 학습하도록 만들기
[244]로봇이 현실 세계에 대해 학습하도록 만들기
 
[243] Deep Learning to help student’s Deep Learning
[243] Deep Learning to help student’s Deep Learning[243] Deep Learning to help student’s Deep Learning
[243] Deep Learning to help student’s Deep Learning
 
[234]Fast & Accurate Data Annotation Pipeline for AI applications
[234]Fast & Accurate Data Annotation Pipeline for AI applications[234]Fast & Accurate Data Annotation Pipeline for AI applications
[234]Fast & Accurate Data Annotation Pipeline for AI applications
 
Old version: [233]대형 컨테이너 클러스터에서의 고가용성 Network Load Balancing
Old version: [233]대형 컨테이너 클러스터에서의 고가용성 Network Load BalancingOld version: [233]대형 컨테이너 클러스터에서의 고가용성 Network Load Balancing
Old version: [233]대형 컨테이너 클러스터에서의 고가용성 Network Load Balancing
 
[226]NAVER 광고 deep click prediction: 모델링부터 서빙까지
[226]NAVER 광고 deep click prediction: 모델링부터 서빙까지[226]NAVER 광고 deep click prediction: 모델링부터 서빙까지
[226]NAVER 광고 deep click prediction: 모델링부터 서빙까지
 
[225]NSML: 머신러닝 플랫폼 서비스하기 & 모델 튜닝 자동화하기
[225]NSML: 머신러닝 플랫폼 서비스하기 & 모델 튜닝 자동화하기[225]NSML: 머신러닝 플랫폼 서비스하기 & 모델 튜닝 자동화하기
[225]NSML: 머신러닝 플랫폼 서비스하기 & 모델 튜닝 자동화하기
 
[224]네이버 검색과 개인화
[224]네이버 검색과 개인화[224]네이버 검색과 개인화
[224]네이버 검색과 개인화
 
[216]Search Reliability Engineering (부제: 지진에도 흔들리지 않는 네이버 검색시스템)
[216]Search Reliability Engineering (부제: 지진에도 흔들리지 않는 네이버 검색시스템)[216]Search Reliability Engineering (부제: 지진에도 흔들리지 않는 네이버 검색시스템)
[216]Search Reliability Engineering (부제: 지진에도 흔들리지 않는 네이버 검색시스템)
 
[214] Ai Serving Platform: 하루 수 억 건의 인퍼런스를 처리하기 위한 고군분투기
[214] Ai Serving Platform: 하루 수 억 건의 인퍼런스를 처리하기 위한 고군분투기[214] Ai Serving Platform: 하루 수 억 건의 인퍼런스를 처리하기 위한 고군분투기
[214] Ai Serving Platform: 하루 수 억 건의 인퍼런스를 처리하기 위한 고군분투기
 
[213] Fashion Visual Search
[213] Fashion Visual Search[213] Fashion Visual Search
[213] Fashion Visual Search
 
[232] TensorRT를 활용한 딥러닝 Inference 최적화
[232] TensorRT를 활용한 딥러닝 Inference 최적화[232] TensorRT를 활용한 딥러닝 Inference 최적화
[232] TensorRT를 활용한 딥러닝 Inference 최적화
 
[242]컴퓨터 비전을 이용한 실내 지도 자동 업데이트 방법: 딥러닝을 통한 POI 변화 탐지
[242]컴퓨터 비전을 이용한 실내 지도 자동 업데이트 방법: 딥러닝을 통한 POI 변화 탐지[242]컴퓨터 비전을 이용한 실내 지도 자동 업데이트 방법: 딥러닝을 통한 POI 변화 탐지
[242]컴퓨터 비전을 이용한 실내 지도 자동 업데이트 방법: 딥러닝을 통한 POI 변화 탐지
 
[212]C3, 데이터 처리에서 서빙까지 가능한 하둡 클러스터
[212]C3, 데이터 처리에서 서빙까지 가능한 하둡 클러스터[212]C3, 데이터 처리에서 서빙까지 가능한 하둡 클러스터
[212]C3, 데이터 처리에서 서빙까지 가능한 하둡 클러스터
 
[223]기계독해 QA: 검색인가, NLP인가?
[223]기계독해 QA: 검색인가, NLP인가?[223]기계독해 QA: 검색인가, NLP인가?
[223]기계독해 QA: 검색인가, NLP인가?
 

[114]angularvs react 김훈민손찬욱

Notes de l'éditeur

  1. Angular2 vs React, React vs Angular2 발표를 맡은 손찬욱, 김훈민 입니다. 안녕하세요
  2. 우리가 왜 Deview라는 이런 큰 무대에서 이런 발표를 할까요? 저는 사내에서 Angular2밋업을 진행하고 있고, 훈민님은 React밋업을 진행하고 있습니다. 자연스럽게 Angular2와 React에 대해 이야기를 하게되었어요. 이야기를 하다보니, 우리가 Anguar2와 React에 대해 좀 많이 오해하고 있다는 것을 알게되었습니다. 다른 개발자분들도 저희같은 입장이라고 생각해서, 저희가 프로젝트를 하면서 겪었던 경험. 그리고 함께 이야기하면서 느꼈던 것을 공유하기 위해 이 자리에 나왔습니다.
  3. 이 발표에서는 프레임워크를 사용한다는 대전제를 두고, 오직, Angular2와 React 에만 집중하도록 하겠습니다.
  4. 이런 발표를 한다고 했을 때, Angular2와 React는 성격이 달라서 비교하기에 적절하지 않다고 이야기하는 분들이 계셨어요. 네, 저희도 알고 있습니다. 그래서 균형의 추를 맞추기 위해서, Angula2와 React Family를 가지고 이야기를 진행하려고 합니다.
  5. 보통 프레임워크를 비교할 때, 이런 비교표를 많이 보셨을 거에요. 그런데, 이런 차이가 실제 개발할 때 크게 느껴지는 부분은 아닙니다. 그냥 참고용. 안심용이죠. 오히려, 파일 사이즈나 성능을 가지고 비교하는 경우가 많습니다.
  6. 그래서 우리도 비교해봤습니다. 파일 사이즈는 어떨까요? Angular2는 무겁고 React는 가벼울거라고 생각을 많이 하시는데. 실제는 별 차이가 없었어요.
  7. Webpack 빌드 기준으로 Angular2는 314k이고, 리액트는 240k였어요. Angular2는 필수 코드 기준으로 AOT 빌드를 적용한 것이고, React는 redux를 포함한 결과입니다. 생각처럼 크게 차이가 안 나죠. 별로 의미가 없는 거 같아요. 그렇다면 성능은 어떨까요?
  8. 오픈소스 벤치마킹 소스인 js-benchmark-framework를 포킹해서 Angular, React, Vanilla만 남기고 테스트를 해봤습니다.
  9. 테스트는 총 6개의 시나리오를 셀레늄으로 반복해서 수행한 결과입니다.
  10. 원래는 항목 별로 세부 수치가 나오는데 요점만 보여드리려고 생략했습니다. vanilla가 1라고 봤을 때, 상대적으로 수행 시간이 몇 배나 더 걸렸는지를 의미하는 수치인데요, 앵귤러가 리액트 보다 아주 약간 느리지만, 큰 차이는 없어보입니다.
  11. 메모리 사용량은 볼까요? Angular2가 조금 더 사용하는 것 같습니다. 하지만, 의미있는 차이라고 보기는 어려울 것 같습니다.
  12. 그럼 어떤 기준을 가지고 이 녀석들을 비교해야할까? 고민하다가 근본적인 질문을 던져봤어요. 우리는 프레임워크는 왜 쓸까요? 결국 좀 더 빠르고, 좀 더 편하고, 좀 더 일관성있게 개발을 하고 싶은 거잖아요? 이걸 한 단어로 뭐라고 하지…를 고민했을 때 생산성이라는 단어가 떠올랐어요. 물론 소프트웨어 산업에서 생산성이라는 단어는 논쟁의 씨앗이죠. 생산성을 측정할 수 있는 객관적인 기준이 없기 때문이에요.
  13. 하지만 흔히 우리가 어떤 기술을 사용할 때 감각적으로 이야기하는, 생산성에 영향을 미치는 것 같다는 키워드는 몇 개 뽑아볼 수 있겠죠. 이런 거죠.
  14. 학습 비용은 우리가 느끼기에 둘 다 비슷했어요. 리액트가 배우기 쉽다고 광고는 하지만 리액트와 함께 사용할 라이브러리를 선택하고 학습하고 조립하는 비용을 무시 못하거든요. 생태계나 신뢰성을 가지고 이야기하기에는 이제 막 첫발을 내디딘 Angular2한테는 무리일테구요. 그래서 이 세 가지를 제외하고 남은 키워드에 초점을 맞춰서 몇 가지 이야기 할 주제를 선정했습니다.
  15. 그래서 다음과 같은 목차로 진행하기로했다.
  16. 생산성하면 가장 먼저 도구를 떠올리게 됩니다. 그 첫 번째가 개발환경이라고 생각됩니다. 이 부분은 할말은 많은데, 할 시간이 없어서 바로 1시간 전에 부득이하게 제외하기로하였습니다. 솔직히, Angular2가 더 좋지만… 발표를 못해 아쉽네요.
  17. JavaScript의 영역이 전에 비에 아주 넓어졌습니다. JavaScript 애플리케이션의 다양성과 복잡성이 함께 증가했어요. 그러면서 동적 언어가 가진 한계를 불평하는 개발자가 늘고 있는 상황입니다. 커뮤니케이션 비용이나 설계 의도 표현이 어렵다는 이야기를 해요. 그래서 정적 타입을 JavaScript로 끌어오려는 시도를 계속하고 있죠. angular2가 typescript를 받아들인 것도 이런 배경이라고 생각합니다.
  18. typescript는 angular만의 언어는 아니죠. react도 typescript를 이용해서 애플리케이션을 개발할 수 있습니다. 무려 typescript 공식 사이트에서 react를 소개하고 있어요.
  19. 그리고 Flow라는 녀석이 있어요.
  20. 페이스북이 만든 정적 타입 검사기에요. 언어와 유사한 특징을 가지고 있어서 사실 그냥 언어 같기도 합니다. React와 별개 프로젝트인데 함께 사용할 수 있어요.
  21. 이 코드가 Flow로 작성한 코드입니다. 그냥 JavaScript에 type을 추가했을 뿐입니다. 그래서 언어라고 보기 애매하다는 말씀을 드린 거고, 실제로 Facebook로 언어라고 이야기하지는 않습니다.
  22. npmdicover.com이라는 사이트에 가면 특정 npm 패키지와 많이 쓰이는 npm 패키지 목록을 볼 수 있습니다. 가서 검색해보시면 react 프로젝트 중, flow 또는 typescript를 함께 쓰는 경우는 4%도 채 안 되요.
  23. 이 코드는 JavaScript로 작성한 예제인데요, Todo 목록을 객체와 배열 리터럴로 선언하고, completeTodos 함수를 completed가 true인 Todo만 가져오는 코드입니다. 아주 흔한 코드죠.
  24. TypeScript로 바꿔볼까요. 이렇게 바뀝니다.
  25. TypeScript에서는 객체 리터럴도 타입을 선언해줘야 합니다. 타입 없이도 쓸 수 있습니다만, 그럼 TypeScript를 사용하는 의미가 없죠. 그러다보니 JavaScript의 장점이 죽는 느낌이 들어요. 번거롭죠. 뭔가를 선언하고 표기해야 해요. 그만큼 비용이 들어간다는 이야기를 하고 있는 겁니다.
  26. 외부 모듈을 사용할 때가 압권입니다. TypeScript에서 외부 모듈을 불러오려면 이런 타입 정의 파일이 필요해요. 이 사진은 jQuery의 타입 정의 파일을 일부를 캡쳐한 모습입니다. 실제로 작성을 해보면 타입의 지원을 받는 다는 느낌이 아니라, 타입을 프로그래밍을 하는 느낌을 받아요.
  27. 자, 이런 녀석을 가져와야 합니다. 이건 제가 실제로 겪은 과정이에요. 어디에서 가져오지? 그래서 검색을 했습니다. 사실 그 전에 ‘타입 정의 파일을 어디에서 찾아야 하는지를 먼저 검색’해서 알아야 했습니다. 그런데 그것도 어렵더라구요.
  28. 어찌어찌 찾아 들어갔습니다. 검색했는데 타입을 제공하지 않아요. 저 보고 만들래요.
  29. 못 만들겠으면 Any로 선언하거나 타입을 선언하지 않고 코딩해야 합니다. 그럼 뭐는 타입을 선언하고 뭐는 타입을 선언하지 않는 상황이 되겠죠. 저는 이렇게 일관성이 깨지는 상황은 좋지 않다고 생각합니다.
  30. 그래서 제가 말씀드리고 싶은 핵심은, 장점이 있다는 거 알고 있습니다. 그런데 비용도 든다는 거에요. 그런데 장점만 이야기해요. 들이는 비용에 비해서 얻는 소득이 있는 상황인지는 따져봐야 할 일이죠. 개발자가 판단해서 결정할 문제죠.
  31. 그런데 왜 Angular2는 마치 언제나 정답인양 TypeScript를 강요하나요? 네? 찬욱 님, 왜 그러는 거에요?
  32. Angular2를 배우려면 Typescript 써야해서 싫다고 하시는 분들 정말 많다.
  33. 물론, Angular2가 js, dart도 지원하지만 기본적으로 ts를 권장하고 있는 것은 사실이다.
  34. 예전에는 TypeScript를 컴파일해서 javascirpt를 만든다는 것 자체가 가장큰 부담이었다. 하지만, Babel와 Webpack 그리고 React의 대중화로 인해, 코드를 transcompile 하는 것은 큰 진입장벽이 아니게 되었다. 이점은 오히려 React에 굉장히 감사하다고 생각한다. 그렇다 하더라도, JavaScript 개발자에게 TypeScript를 새로 배우라는 것은 쉽든 쉽지 않든 굉장히 부담스러운 일인 것은 분명하다. 하지만, 훈민님이 이야기한 것처럼, TypeScript가 그냥 type을 위한 언어는 아니다. 이것은 왜 Google이 TypeScript를 선택했는지를 살펴보면 알수 있다.
  35. 구글은 타입 문제 이전에 “언어 자체의 생산성 향상”을 고민 했다. 자바스크립트가 유연한 언어이지만, 유연한 만큼 잘못 사용하면 많은 문제를 일으킬 수 있기 때문에, google은 Angular2를 만드는 동시에 새로운 언어를 만들고 싶어했다. 그것이 바로 AtScript이다. AtScript는 Javascript를 보완한 ES2015 스펙을 사용하고자 했으며, 타입형 언어를 도입하려고했다. 더불어, 간결한 표현을 위해 Metadata를 도입하려고했다. 뿐만아니라, 자신이 만드는 언어를 표준으로 지정하기 위해, 웹표준화 위원화인 TC39에 건의하는 일도 진행했다. ——- 그런데, 막상 만들고 나서 보니깐. 이런 고민들을 MS, Facebook에서도 같이 하고 있던 걸 알게되었고, 궁극적으로 구글은 angular2가 추구하는 방향성과 MS의 Typescript의 방향성이 상응한다고 판단되어 Angular2에서 사용하기로 결정습니다.
  36. 앞에서 훈민님이 이야기 하신 것처럼 비용과 소득 이야기를 해볼까요? 분명, 따져볼 필요가 있습니다.
  37. 타입을 사용한다면… TypeScript는 JavaScript에서 처리해야만 하던 방어 코드들을 작성할 필요가 없으며, 발생할 수있는 잠재적인 버그를 타입을 통해 해결할수 있다. 뿐만 아니라, 코드 의도 또한 명확해 지기 때문에 의사소통의 비용도 줄일수 있다. 이런 장점은 React에서도 인지하였기에, 정적으로 flow로 검사하고, 동적으로 React의 Prototypes를 소스에 지정한다고 생각한다.
  38. 예전의 Typescript는 타입을 위한 언어였을지 모르지만, 이름과 다르게 지금의 Typesctipt는 웹표준에 지대한 영향력을 끼치고 있는 구글과 협업 함으로써 타입 이상의 의미를 갖게되었다. typescript가 가지고 있는 decorator는 이미 TC39에 제안이 되어 진행되어 있고, type은 아직도 논의가 계속되고 있습니다. Typescript는 새로운 언어가 아니라 바로. javaScript의 superset이 된것이다.
  39. Typescript를 익히는 비용이 Javascript 개발자에게는 어떻게 보면 미리 투자하는 선투자의 개념이기 때문에, 손해본다고 생각할 필요는 없다고 생각한다. 이 부분은 제가 공격을 많이 받을것 같으니깐 빠르게 다른 주제로 넘어가도록 하겠습니다.
  40. 컴포넌트는 사전적으로 “하나의 독립된 기능을 수행하는 최소 단위 UI”를 나타냅니다.
  41. 좀 더 구체적으로 웹페이지에서의 컴포넌트라면, HTML + JS + CSS를 하나의 기능으로 묶을수 있는 것이 웹페이지에서의 컴포넌트라고 생각한다. 이렇게 묶을 수 있어야. 컴포넌트의 이식성이 높아지고, 이로 인해 재사용성을 높일수 있다.
  42. Angular2의 컴포넌트는 이런 점에서 훌륭하다. HTML, CSS, JS 를 하나로 묶어서 관리할 수 있고, 더불어, CSS의 캡슐화를 지원하기 때문에, 외부의 CSS에 영향을 받지 않는다. 뿐만아니라, Native 로 옵션을 바꾸면, 웹컴포넌트로 바로 사용할 수 도 있다. 하지만, React는 어떤가?
  43. React는 기본적으로 CSS 캡슐화를 지원하지 않기 때문에, 외부 CSS에 컴포넌트가 영향을 받을수 있다. 한마디로, 반쪽짜리 컴포넌트이다. 훈민님 제말이 맞죠? —- 훈민 파트 —- 혹시 Webpack이라고 들어보셨나요? Webpack의 loader 중에 css-loader라고 있습니다. 이 녀석을 이용하면 CSS를 지역화 할 수 있어요. 하지만 아쉬운 건 사실이에요. 꼼수에 가깝고 번거로우니까요. 인정!
  44. 전 관대한 사람이기 때문에 그정도는 충분히 이해한다. 하지만, React가 정이 안가는 이유는 바로, JavaScript 코드와 JSX가 섞여 있다는 것이다.
  45. 지금 보는게 React 코드인데, 보시면 아시겠지만, 이게 JavaScript도 아니고, 마크업도 아니고, 뭣도 아니다. 거부감이 드는 것은 그렇다 치더라도, Javascript와 마크업 개발자 다른 상황에서는 협업하는게 쉬운일이 아니다. 더군다나. HTML과 코드가 섞여 있다보니, 코드를 적용하기 전까지 디자인 확인도 쉽지 않다. 전 관대한 사람이니깐, 까짓거 자바스크립트 개발자인 내가 붙여놔도 된다. 하지만,
  46. 더 심한 것은 바로 이겁니다. Angular2에서는 HTML을 그냥 넣어도 됩니다. 왜? Angular2는 표준 HTML을 확장한 것이니깐. 그냥 되요. 하지만, React는 어떨까요? 우리가 알고 있는 HTML이 아닙니다. 훈민님 className, defaultValue가 HTML 스펙인가요? 이것도 좋아요. 전 관대하니깐요. 그런데 React의 템플릿은 꼭! root가 있는 마크업을 주어야해요. 아니면 에러를 뱉죠. 이정도면 거의 뭐 새로운 언어 아닌가요? 아까 Typescript 이야기하셨는데… 왜 React는JSX를 강요하나요? 왜 강요하죠?
  47. 네, 맞습니다. 찬욱 님이 말씀하신 부분 인정하구요, HTML과는 다른 특성으로 인해 협업에 몇 가지 불리한 부분이 있다는 점은 사실이에요. 그런데 마크업 개발자가 JavaScript를 전혀 모르는 경우가 아니라면 이게 생산성에 치명적인 영향을 미칠 정도라고는 생각 안 합니다. 실제로 제가 그렇게 일하고 있구요. 그리고 한 가지 말씀 드리고 싶은 게 있는데, 템플릿은 마치 이 문제에서 자유로운 것처럼 이야기하는 것은 좀 이상해요.
  48. 한 가지 예를 들어볼게요. 마크업 개발자가 이런 마크업 코드를 만들어서 JavaScript 개발자한테 넘겼어요. 그러면 JavaScript 개발자가 뭘 하죠? 앵귤러를 사용한다고 가정해보죠. 이런 걸 하죠.
  49. 마크업에다가 논리 코드, 디렉티브를 막 집어넣죠. 정적인 마크업 구조에 동적인 행위를 껴넣는 거죠. 그럼 이렇게 바뀌어요.
  50. 이미 구조 안에다가 행위를 집어넣는 순간, 마크업은 그 자체로 순수함을 잃었어요. 이 상태에서 마크업이 바뀌면 어떻게 되나요? 마크업 바로 통으로 복사해서 못 붙여넣죠. 그래서 JavaScript 개발자가 diff 확인해가면서 붙여넣는 거잖아요? 저는 이 문제는 React나 Angular나 둘 다 풀지 못했다고 생각합니다. 앞으로 프론트엔드 기술이 풀어야 할 숙제죠. 지금으로선 협업 방식을 개선하는 걸로 푸는 게 가장 좋은 방법일 것 같아요. 그렇게 협업할 때 불리한 점이 있다면 인정, 하지만 마치 템플릿은 협업하기 아주 좋은 도구인냥 이야기하는 건 인정 못 하겠습니다. 그리고 한 가지 이 자리에서 풀고 싶은 오해가 하나 더 있어요. 찬욱 님 저 시간 좀 쓸게요, 괜찮아요?
  51. JSX는 HTML이 아닙니다. 템플릿도 아니에요. Syntactic Sugar, 달콤한 문법이에요. 본질적으로 JavaScript라고 보는 게 맞습니다.
  52. JavaScript로 DOM 노드를 생성해보신 적 있으세요? 명령형 API로 계층형 DOM 노드를 표현하기가 상당히 힘들어요. React도 마찬가지였어요. 이 코드를 보세요. 가독성이 떨어지죠. 이런 코드로 트리 구조를 표현한다고 생각해보세요.
  53. 그런데 JSX를 이용하면 이렇게 표현할 수 있어요. 원래 JavaSCript인 코드를 보기 좋게 표현하려고 HTML 문법을 빌려온 거에요. 그래서 단순히 구조를 표현하는 것 이상의 역할을 할 수 있어요. 본질은 JavaScript인데, 여기에 마크업의 표현력을 얹은 문법이거든요.
  54. 그래서 자바스크립트처럼 디버깅을 할 수 있습니다. 물론 약간의 제약은 있지만 가끔 유용하게 쓰일 데가 있습니다.
  55. React는 애초에 구조와 기능은 하나의 논리, 즉 같은 관심사라는 생각에 바탕을 두고 만들어졌어요. 그래서 구조와 기능을 함께 묶고 싶어해요. 실제로 컴포넌트는 구조에 행위를 포함합니다. 구조만 있는 컴포넌트는 없죠. 적어도 react와 angular가 이야기하는 컴포넌트는 그렇습니다. 그래서 둘은 원래 하나에요. 하나의 논리라서 함께 있을 때 더 자연스럽게 읽히죠. JSX 이전에는 JavaScript 안에 HTML을 자연스럽게 표현하기가 어려웠어요. 그래서 템플릿 같은 게 등장했죠. 그런데 JSX가 나오면서 상황이 좀 달라진거죠. JSX를 이용하면 구조와 행위를 함께 표현할 수 있고 설계상 장점이 있죠. 예제를 보여드릴게요.
  56. 이 코드는 Sortable이라는 컴포넌트에 하위 컴포넌트를 외부에서 주입하는 설계를 보여줍니다. Sortable이라는 상위 컴포넌트를 정의하고,
  57. 내부에 Box 컴포넌트를 집어넣으면 SortableBox가 되고, Triangle 컴포넌트를 집어넣으면 SortableTriangle가 되죠.
  58. 이런 기법을 High Order Component라고 합니다. 의존성 주입이라는 설계 기법을 JSX로 표현함과 동시에 컴포넌트의 계층 구조까지 함께 표현하고 있습니다.
  59. 생성자를 이용한 DI나, 함수를 조합하는 방식으로 문제를 풀었다면 아마 이랬을 거에요. 어떤 게 더 잘 읽히시나요? 템플릿은 행위랑 구조를 엄격하게 분리하기 때문에 이런 식의 표현을 할 수는 있을지언정, 자연스럽지는 않죠.
  60. 정리하자면, JavaScript와 마크업 개발자가 나뉘어 있는 경우, 분명 불리한 점이 있다는 점 인정합니다. 하지만 역으로 한 명이 프론트엔드 전체를 담당하는 경우에는 오히려 컴포넌트 구현에 장점이 더 많다고 생각해요.
  61. 프론트엔드 설계에 MVC가 들어오면서 View와 Model을 분리하는 경우는 아주 흔해졌죠. 상태를 View와 Model 양쪽으로 분리하면서 데이터를 어떻게 쉽고 간편하게 동기화할 것인가는 이제 중요한 문제에요. UI 개발 프레임워크는 이런 데이터 동기화에 대한 각자의 솔루션을 제공합니다. 이 문제를 어떻게 푸느냐에 따라서 기술의 색깔이 달라지거든요.
  62. Angular는 데이터 바인딩으로 유명해요. 처음 Angular가 나왔을 때 데이터 바인딩으로 인기를 많이 끌었죠. DOM의 상태가 바뀌면 이를 View가 받아서 Model로 전달합니다. 화살표의 방향을 잘 봐주세요.
  63. 이런 흐름은 반대로도 동작합니다. Model의 상태가 바뀌면 View가 DOM으로 상태 변경을 전달하고, 이렇게 DOM의 상태를 변경합니다.
  64. 실제로는 이렇겠죠. 네, 이게 유명한 2-way-binding이죠. 가운데 View가 이 모든 마법을 수행해요. 데이터 바인딩은 객체가 아니라 프로퍼티 단위로 이루어져요. 단위가 작죠. 그래서 사실은 화살표가 이렇게 단순하지 않습니다.
  65. 이렇겠죠. 그래도 멋져요. 그런데, 애플리케이션이 커지면서 이런 흐름이 많아지면 어떨까요?
  66. 이런 예쁜 그림이 나올 것으로 기대를 하지만, 실제는 그렇지 않죠. View와 Model의 관계는 항상 1:1이 아니에요. 복잡하게 얽히죠.
  67. 막 열심히 개발하다가 어느 날 돌아보면 이런 그림이 나와요. 실상은 이 보다 더 복잡할 수 있습니다. 물론 잘 쓰면 좋아요. 그런데 관리가 쉽지 않다는 거죠.
  68. 그래서 React는 좀 다른 방식으로 문제를 풀었어요. DOM을 통해서 사용자의 요청이 들어오면 View가 받아서 상태를 변경합니다. 화살표의 방향을 잘 봐주세요.
  69. View의 상태가 바뀌면 그냥 DOM을 새로 그려요. 네, 그냥 새로 그립니다.
  70. 물론 항상 새로 그리는 건 아니죠. React는 현재 DOM의 상태를 반영하는 DOM 객체를 만들어서 메모리에 관리하는데, 이게 Virtual DOM이에요.
  71. 사용자의 요청이 들어오면 새로 바뀐 상태 정보를 이용해서 새로운 Virtual DOM을 하나 만듭니다.
  72. 그리고 이전의 Virtual DOM과 새로 만든 Virtual DOM의 상태를 비교해서 바뀐 부분만 찾아서 DOM에 반영하죠. 이런 일련의 과정에 개발자가 개입할 필요가 없기 때문에 그냥 별 신경쓰지 않고 완전히 새로 그리는 것과 유사한 경험을 하는 거죠. 컴포넌트는 트리 형태의 계층 구조를 이루요. 이 때도 데이터는 단방향으로 흐릅니다. 한 번 볼까요.
  73. 컴포넌트가 트리 구조를 이루듯이, Virtual DOM도 트리 구조를 이뤄요.
  74. 특정 노드에서 변경이 발생하면, 변경이 발생한 노드를 시작으로 자식 노드를 포함하는 Virtual DOM을 새로 만듭니다.
  75. 좌측이 변경 전이고, 우측이 변경 후에 새로 만든 Virtual DOM이에요.
  76. 그 다음에는 변경 전과 변경 후, 두 개의 Virtual DOM을 서로 비교해서 바뀐 노드를 찾습니다. 찾은 후에는?
  77. 네, 바뀐 부분을 실제 DOM에 적용하는 거죠. 이 모든 과정이 단방향으로 일관성있게 흘러요. 이거 어때요 찬욱님? 좀 괜찮지 않아요?
  78. 양방향 때문에 성능문제에 직면하고, 데이터 흐름의 복잡도가 증가하기도 했다. 맞아요. Angular1에서 그랬어요. 하지만, 이런 양방향 데이터 바인딩이 오히려 효율적인 경우도 있답니다. 특히 Form 처리가 이러한 경우입니다.
  79. 이렇게 이야기 했지만… 솔직히 데이터 동기화에 대해서는 React가 Angular보다 더 나은 솔루션을 제시했다고 생각한다. React 짱이다.
  80. 하지만, Angular2에서는 이 부분에 대한 정말 많은 고민을 한것 같다.
  81. 그 첫번째로. 양방향 데이터 동기화에 대해 부정적의견을 받아들인다.
  82. 그래서 Angular1에서 기본으로 제공했던 양방향 데이터 바인딩을
  83. 앵귤러2에서는 단방향 데이터 바인딩을 기본으로 하며, 사용을 권장하고 있다. 뿐만아니라, Angular2에서도 React와 같이 데이터 흐름 자체도 단방향 처리에 적합하도록 변경하였다.
  84. React와 굉장히 유사하지 않는가? Virtual DOM 대신, 각각의 컴포넌트가 자신의 Change Detector를 가지고 있어, 변경여부를 실제 DOM이 아닌 객체로 판단한다. 판단 또한 React와 같이 부모에서 자식까지 쭉~ 체크하고, DOM 은 딱! 한번 반영한다.
  85. Angular1에서는 timeout대신 $timeout을 써야하고, ajax를 쓰려면 Angular가 제공하는 $http만을 사용해야만 했다. 더군다나, 사용자가 코드상에서 특정 모델을 변경하기 위해서 $scope.apply() 같은 작업또한 경우에 따라서는 해줘야만 했어요. 이렇게 한 이유는 바로, 데이터 동기화를 언제해야하는지를 프레임워크에게 알려줘야만 했기에, 이런 wrapper 메소드들을 제공했다. Angular2도 그럴까요?
  86. zone을 도입해서. Angular1의 문제점을 개선했습니다. zone은 Javascript의 실행영역을 뜻하고요, zone 라이브러리는 브라우저가 관리하는 실행영역을 S/W적으로 구현한 것입니다. zone은 원래 dart의 spec이었는데, js로 포팅을 해서, Angular2에서 코어로 쓰고 있습니다. 물론, zone도 TC39 에 제안되어 있는 스펙입니다. 즉, 곧 표준이 된다는 거죠. 이 zone을 이용하면, 실제 그 실행영역에서 발생하는 작업들의 프로파일이 가능합니다.
  87. deletegate.invokeTask가 비동기 액션이 실행되는 시점의 Angular2 코드입니다. 보시는 것처럼, Zone을 이용하면, 작업이 최종적으로 끝나는 시점 finally에서 데이터 동기화 시점을 알수 있습니다.
  88. 그래서 이제는 요렇게 사용할수 있겠죠 Angular 전용 객체나 메소드를 사용할 필요가 없고, 모델도 그냥 바꾸면 반영이 됩니다.
  89. 좀 정리하면, Angular2의 데이터 동기화는 ng1의 데이터바인딩에 React의 심플함을 더하고, 마지막으로 zone을 이용해서 사용성까지 개선했습니다. 훈민님… 정말 쩔지 않나요?
  90. 정리하자면, 방식의 차이는 있을지 언정 두 프레임워크 모두, “DOM이 아닌 모델에 집중”하여 개발시 비즈니스 에 더 집중할수 있도록 도와주고 있습니다.
  91. 개발자 입장에서 차이가 있다면 React는 model의 변경사항이 View로 동기화되는 것은 프레임워크가 맡은 반면, 그 반대는 개발자가 명시적으로 호출해야합니다.
  92. Angualr2의 경우는 모두 프레임워크가 자동으로 데이터 동기화를 진행합니다. 꽤 편리하지 않나요?
  93. UI 개발자는 비동기에 둘러쌓여서 살죠. 피할 수 없는 숙명이자, 풀기 어려운 과제입니다. 다 비동기에요. 물론 UI개발만 그런 건 아니에요. 전반적으로 비동기 프로그래밍의 중요성이 커지고 있는 상황입니다. 그런데 인간이 사고하는 방식은 원래 비동기와 거리가 있어서 힘들어요. 그래서 우리는 여러 기술의 지원을 받고 있습니다.
  94. 이런 비동기 처리 해법 중에 요즘 많이 이야기 나오는 게 RxJS인 거 같아요. 듣자하니 Angular2가 RxJS랑 손을 잡았더라구요? 맞나요? 찬욱님? (네, 맞습니다) 그래서 비동기 챕터에서는 RxJS를 가지고 이야기를 좀 해야할 것 같아요. React는 라이브러리를 지향하는 특성상, React가 공식적으로 RxJS를 도입하려는 움직임은 없어요. 다만 커뮤니티가 열심히 움직이고 있죠.
  95. RxJS를 설계 수준에 적용해서 Flux 아키텍처를 대신한다든지,
  96. 아니면 이런 식으로 비동기 서버 API 호출에 사용하기도 하죠. 주로 React가 제공하지 않는 부분을 RxJS로 채우려는 시도가 많이 있어왔고, 지금도 있죠. 하지만 대중의 반응은 심심해요. 저도 리액티브 프로그래밍에 관심이 있어서 rxjs를 공부를 해봤는데, 학습비용이 매우 높아요. 이런 비용을 감당하면서 까지 굳이 rxjs를 써야 할 필요성을 못 느끼고 있는 것일지도 모르겠어요. 사실 비동기에 대한 해법을 rx만 제공하는 건 아니거든요.
  97. 언어 차원에서 제공하는 이런 해법이 있죠. 하지만 이런 스펙들은 비동기 코드의 작성을 도와줄 뿐, 비동기 애플리케이션의 높은 복잡도를 완전히 해결해주지는 못합니다. 그래서 비동기와 직접적으로 관련성은 없을지라도, 설계 수준의 해법이 따로 필요하죠.
  98. 설계 수준에서는 Redux가 리액티브 프로그래밍의 개념을 거부감 없이 받아들이도록 잘 포장을 했어요. Observable이 구독자에게 데이터를 밀어넣는 과정은,
  99. Store가 Component로 상태를 밀어넣는 것과 유사합니다.
  100. 반대로 Subject가 구독자에게 메시지를 밀어넣는 모습은,
  101. 컴포넌트가 액션을 스토어로 디스패칭하는 과정과 유사하죠.
  102. 결국 자세히 들여다보면 Redux 구조에서 데이터가 흐르는 흐름은 전체 시스템의 요소들을 하나의 스트림으로 연결한 모양을 만듭니다.
  103. 스트림이 흐르는 사이사이에 미들웨어를 껴넣을 수 있는데, 이건 마치 Rx의 오퍼레이터와 유사해요. 이게 Redux 설계에 숨어있는 리액티브입니다.
  104. Redux는 애플리케이션의 상태 관리 설계에 대한 설계 솔루션이기 때문에 비동기 코드 수준의 문제에 대한 해법을 제시하지는 않습니다. RxJS가 껴들어갈 틈이 있는 거죠. 그래서 RxJS와 Redux를 함께 결합해서 사용하려는 시도, 역시 최근에 간혹 보여요. rxjs가 나온 건 2012년이에요. 리액티브 프로그래밍의 개념은 훨씬 이전에 등장했죠. 프론트엔드 분야에서 rxjs는 그동안 비주류였어요. 개념이 어렵고, 생각을 전환하는 게 쉽지 않아요. 오퍼레이터를 이해 못하면 코드를 읽을 수가 없습니다. 그리고 상당히 무겁죠.
  105. 이런 상황에서 angular2가 rxjs를 코어로 받아들였다는 사실이 저는 재밌어요. 생태계 전반에 어떤 영향을 미칠지 궁금해요. 쉽지는 않을 것 같아요. 앞에서 말씀드렸던 단점들이 좀 마음에 걸리거든요. 어떻게 생각하세요, 찬욱님? rxjs 써보셨어요?
  106. Angular2는 프레임워크 내부에서는 RxJS를 잘 사용하고 있습니다.
  107. 이거 기억나시죠? zone 에서는 비동기 작업이 끝나면 onLeave라는 메소드를 호출합니다.
  108. onLeave 메소드는 결과론적으로 EventEmitter의 emit을 호출하여 이벤트를 발생합니다. 여기까지는 그냥 이벤트 처리 같지만, 실제로 EventEmitter의 emit은 RxJS의 Subject를 이용하여 발생한 것입니다.
  109. Angular2는 비동기 액션에 대한 산발적인 이벤트를 RxJS 통해, 스트림 형태로 처리할수 있도록 효과적으로 변경한거죠.
  110. Angular2는 항상 최상위 부터 하위로 변경여부를 확인합니다. 약간 비효율적이라고 생각하지 않았나요?
  111. Angular2에서는 Observable과 Component의 ChangeDetection 전략만 조정을 하면 굉장히 효율적으로 Change detection을 할수 있습니다. 만약 이 부분이 Observable에 의해 데이터가 변경되었다면, Angular2는 해당 ChangeDetector가 속해있는 상,하위 노드의 변경만을 확인할수 있습니다.
  112. Angular2의 HTTP, FORM이 RxJS 또한 지원하기 때문에, 필요하다면 RxJS를 바로 쓸수 있다. operator를 이용하여 데이터를 변경하거나 지연시키는 일등을 좀 손쉽게 할수 있다.
  113. 또한, 컴포넌트에서 필요한 경우, 서비스에게 데이터를 매번 요청하는 pull 방식이 아니라, 컴포넌트가 서비스를 subscribe하는 push 방식이기 때문에, 서비스와 컴포넌트의 관계가 느슨해지고, 데이터를 제어하는 주체가 컴포넌트가 되어 side effect에 덜 취약해진다.
  114. RxJS을 익히는 것은 분명, 높은 학습비용이 든다. 비동기에 대한 다른 대안도 많이 있는 상황에서, Angular2가 굳이 RxJS를 비동기의 솔루션으로 제시한 이유에 대해서는 아직 경험이 부족하기 때문에, 솔직히 잘 모르겠다. 장점은 분명이 있지만, 이게 정말 적합한 솔루션인지는 앞으로 계속 지켜봐야만 할 것 같다.
  115. 앞에서 총 5개의 주제로 각 프레임워크 입장에서 이야기해 봤다. 우리는 어떤 프레임워크를 선택해야할까요? 이 부분이 정말 여러분이 궁금해할 부분인 것 같다. 훈민님과 제가 이야기를 하면 느꼈던 가장 큰 점은 두 프레임워크는 확실히 자신만의 방향성을 가지고 있었다.
  116. Angular2는 최소의 기능. 그리고 프로젝트 개발시 닥치는 문제들의 기본적인 솔루션을 제공하고 그외는 개발자의 선택에 맡긴다. 뿐만 아니라, 브라우저 벤더 주도하에 진행되고 있다보니 가능하면 웹표준을 지향하려는 경향이 강한것 같다. 반면, React는 최소의 기능만을 제공하고 있다. 나머지는 개발자와 커뮤니티의 선택과 결정을 더 중요시 여기는 것 같다.
  117. 프레임워크를 써야하는지? Angular2는 웹에서 처리할 문제의 솔루션을 제시한다. Angular2는 유연성을 갖추고 있다. redux도 가능하다. Angular2는 웹표준을
  118. 오늘 사실 저는 두 기술을 비교함으로써 누가 더 낫다라는 이야기를 하려고 했던 게 아니다. 그 보다는 비교를 통해서 장점과 단점이 어떻게 서로 통하는지를 보여드리고 싶었다. 개발자로서 우리가 하는 대부분의 선택에는 트레이드-오프가 존재하다. 그래서 고민, 선택, 학습의 굴레에서 평생 벗어날 수 없다. 고민 없이 개발할 수 있다는 말, 너무 믿지 마시라. 고민 없이 할 수 있는 일은 기계가 더 잘한다. Angular2가 All-in-One 프레임워크라고 하지만 쓰다보면 결국 각자가 처한 상황에 맞는 솔루션을 찾게 될거다. 그때가 되면 기본으로 제공하는 것들이 거추장스럽게 느껴지실거다. 여러 분들이 처한 상황을 먼저 들여다보시고 최적의 대안을 선택하시라. 그래서 저는 개발자들에게 좀 더 많은 선택권을 주는 React를 추천한다.