9. * 생성자
this 는 함수 자신을 가리킴
* 프로토타입
생성자로 만들어진 객체들은 모두 이 prototype 객체를 공유
생성자에서 메소드를 만든 것 보다 prototype으로 만든게 좋음
prototype은 한번 만들고 공유하지만
생성자에서 만든건 객체를 만들 때 마다 메소드도 하나씩 만들어지
때문에 메모리 낭비임
상속 : https://www.zerocho.com/category/JavaScript/post/573d812680f0b9102dc370b7
자바스크립트 식 객체지향 : 생성자, 프로토타입, 상속
10. * 1995년 Net Scape사의 브랜든 아이크에 의해 개발됨
* Mocha 라는 언어로 시작
* ECMA가 ECMAScript라는 이름으로 표준화 진행
* MS가 채택 JScript를 만들어 IE에 포함
* Net Scape 망함
* 구글이 Ajax 사용하면서 Ajax가 발굴되었고 JS가 대박남
* 그러나 각 벤더사마다 다름 => 표준이 없음
* ES5 제정됨 (2009)
* 2013년 Node.js의 등장으로 서버사이드도 가능해짐
* 2015 ES6 발표
자바스크립트 역사
11. * 동적타입
* 약타입
* 크로스 브라우징 문제
* 가독성 문제
* 모듈 관리 시스템의 부재
* 끔찍한 DOM 조작
* 라이브러리 재 로드
* 전역변수 문제점
그로인해 쏟아지는 많은 라이브러리와 프레임워크
(순수)자바스크립트 문제점
18. * 2010년에 발표됨
* 복잡해지는 웹페이지를 감당하기 위해 나온 JS 프레임워
크
* MVR 패턴을 적용해 웹 어플리케이션을 개발할 수 있도
록 돕는 프레임워크
* 장점 : 파일의 크기가 작음(타 프레임워크 30~70K 하지
만 백본은 6.4K 이다),
* 규제가 널널함(자유도 높음), 경량 어플리케이션에 적합
* 뷰와 로직을 분리할 수 있어서 코드 유지보수 및 수정 확
장이 쉽다.
19.
20. * 2009년에 처음 발표
* 구글이 지원중
* 큰 커뮤니티 있음
* 양방향 데이터 바인딩
* Model과 View 에서 사용되고 있는 데이터를 연결해서 어느 한쪽
에서 데이터값이 변하면 다른 쪽도 바로 업데이트
* View와 Model이 연결됨(VM) =>
* Model이 바뀌면 컨트롤러와 연결된 뷰에서
자동으로 바뀐 Data를 화면에 보여줌 (MVVM)
* 즉, 이벤트 관련 코드가 줄어든다 => 코드의 양이 줄어듦
* 장점: 테스트코드 작성이 쉬움(테스트 주도적), 양방향 바인딩,
커스텀 태그
* 단점: DOM조작 세세하게 못함, 러닝커브있음
24. * 버그 발견시점 앞당길 수 있음
* 리팩토링 용이해짐
* 타입오류 해결할 수 있음
정적 타입 시스템을 통해
25. * 2012년에 공개
* 자바스크립트 슈퍼셋인 오픈소스 프로그래밍 언어
* 마소에서 개발, 유지 중
* 엄격한 문법, type에 문법적 제약
* type을 검사하는 코드를 적지 않아도 됨
* 원하는 타입을 정의하고 프로그래밍 하면 자바스크립트
로 컴파일됨
* 크로스 브라우징 문제 해결
* 약타입, 동적타입 문제 해결
* JS 가독성 문제 해결
* 구글 내부 공식 언어
27. * facebook이 개발
* 자바스크립트 정적타입 분석기
* ES6 의 타입 검증도구
* 즉, 이미 짜여진 자바스크립트를 분석
* 타입이 모호한 경우 어노테이션을 추가해 타입을 정의할 수 있음
* 새로운 언어를 정의한게 아님
Flow는 아래와 같은 자바스크립트의 일반적인 버그들을
프로그램을 실행하기 전에 잡아낼 수 있다.
- 암묵적 타입 변환
- Null 참조
- 그리고 무시무시한 'undefined is not a function'
추가: https://blog.seulgi.kim/2016/01/flow-vs-typescript.html
30. * 단방향 데이터 흐름
* 페이스북이 만든, 뷰 부분을 컴포넌트로 만들기 위한 라이브러리
* 높은 자유도
* JSX
* 지속해서 데이터가 변화하는 대규모 어플리케이션을 구축하기 위함
* 재사용 가능한 UI컴포넌트를 만들기 위한 라이브러리
* Data Flow
* 단방향 데이터흐름 지향 = > 흐름 이해하기 쉬움
* Virtual DOM => 브라우저에 의존적이지 않음, 테스트 쉬움, 빠르다
35. Virtual DOM
변경된 부분
브라우저가
DOM을 해석
후 랜더링
Virtual DOM 생성변경된 부분
<<굉장히 비싼 비용
바뀐부분을 기존 DOM과
비교
바뀐부분만 변경(DOM이 같고 value 가
다르면 속성(props)만 변경
관련 영상
36. * 공식문서가 자세함
* 양방향 바인딩과 컴포넌트, MVVM
* 데이터 바인딩과 컴포넌트에만 집중 = > React와 유사
* 양방향 바인딩 => Angular과 유사
* Angular =>프레임워크에 내재
* React => 커뮤니티에 맡김
* Vue => 공식에서 별도로 관리 및 제공
* 기존의 인프라와 쉽게 통합 가능함
* 작고 가벼움
* 그러나 자원부족(시장 점유율이 낮음)
41. * RxJS는 ReactiveX의 JavaScript 구현체
* ReactiveX는 옵서버 시퀀스를 이용해
비동기 이벤트 기반의 프로그램으로
데이터 스트림을 처리하는 라이브러리.
* RxJS는 비동기 처리의 흐름을 효율적으로 제어해
콜백 지옥 문제를 해결할 수 있다
* Ajax 상위호환
43. Package Management System
패키지 다운, 설치, 빌드, 업그레이드, 의존성관리 등을
쉽게 이용할 수 있도록 도와주는 소프트웨어
Ex) Python’s pip, Ruby’s gem
Package manager
44. 자바스크립트로 작성되어있음
기존 모듈 패키징이 엉망이라서
Isaac Z. Schlueter가 개발해 2010에 발표
패키지관리자와 레지스트리는 npm사에 의해 관리됨
But
1. 패키지가 많아지면 빌드성능이 떨어짐
2. 보안 이슈
3. 버전 이슈
4. 패키지가 중복으로 설치될 수 있음
46. * 2014년에 등장
* 6to5 라는 이름이였음
* ES6+ 코드를 이전 브라우저 호환 코드로 컴파일 (트랜스파
일링)
47. * 모듈시스템 구성 기능, 로더, 빠른 컴파일 속도
* 프로젝트 전체를 한 단위로 분석
* 지정한 메인 파일에서 시작해
* 자바스크립트의 require과 import문을 참고해
* 프로젝트의 모든 의존성을 조사하고
* 로더를 이용해 처리 후
* 번들로 묶은 자바스크립트 파일을 생성함
* 코드의 양이 많아지면서 모듈로 나누기 시작
* 하지만 그 모듈을 관리하는 시스템이 JS엔 없음
48.
49. 왜 이렇게 많은
JS 라이브러리, 프레임워크, 도구들이 있는가?
구현하고자 하는게 많아지면서
코드가 복잡해졌기 때문
하지만 자바스크립트는
그러한 복잡도를 예상하지 못했음
그러한 허점들을 개선하기 위해 등장