Wanna be a thinker

■Javascript

1. 개요
- 동적으로 반응하는 웹 페이지를 만들기 위한 스크립트 언어.

2. 등장 배경
- www의 일반인 사용의 증가로 상대에 따라 다르게 반응하는 웹 페이지가 필요.
- 1995. HTML 페이지에 움직임을 주고 싶었던 NetScape사의 의뢰로 Branden Erich가 제작.
  → 웹 문서의 내용을 동적으로 변경하거나 이벤트를 적용할 수 있게 됨.

3. 등장 후 흐름
- 타 브라우저 회사에서 유사 언어를 출시, 개발자들은 각 브라우저의 호환성으로 인해 고생.
  → NetScape사는 표준화 단체인 ECMA International에 표준화를 요청, 1997.7에 표준 완성.
  → 당시, SUN사가 'JAVA'라는 이름을 상표로 등록해놓았기 때문에, 표준 언어 이름을 'ECMA Script'로 결정.

- 1997. 페이지의 DOM을 다뤄 컨텐츠, 스타일을 변화하고 요소를 보여주거나 숨기는 동적 HTML이 등장함.
- 1999. IE5에서 소개된 XMLHttpRequest API가 나와 Client측 Script를 HTTP(S)로 서버에 요청하고, 텍스트 형식으로
  데이터를 받을 수 있게 됨.

- 2001. Douglas Crockford가 텍스트 형식으로 데이터를 저장하는 자바스크립트 문법을 'JSON'이라고 명명하여 문서로 만들음.
- 2004. 규모가 큰 자바스크립트 프로그래밍을 위한 프레임워크인 Dojo Toolkit이 등장함.
- 2005. Ajax를 이용해 구글이 구글Maps를 소개, 이후 Ajax의 인기가 상승하고, XML 대신 JSON의 사용이 증가함.

- 2006. 크로스 브라우징을 위해 고생하는 개발자를 위해 jQuery가 등장하여 브라우저의 차이를 넘어선 추상화와
  DOM을 손쉽게 쿼리 및 수정하기 위한 API를 제공.
  * jQuery는 같은 코드로 여러 브라우저에서 같은 동작을 하게 해주고, CSS 형식의 선택자로 

    DOM을 쉽게 선택, 제어하는 방법을 제공.

- 2008. V8이라는 빠른 자바스크립트 엔진이 탑재된 구글 크롬이 등장하여 자바스크립트가 느리다는 인식을 바꿈.

- 2009. Ryan Dahl에 의해 Node.js가 개발되어 자바스크립트의 영역을 서버 사이드로 넓힐 수 있게 됨.

  클라이언트, 서버 둘 다 자바스크립트로 프로그래밍 할 수 있었기 때문에 풀스택 개발자가 증가함.

- 이후, 클라이언트 사이드에도 MVC 패턴을 활용하려는 움직임이 증가하여 여러 자바스크립트 프레임워크가 탄생함.

  Backbone.js, Ember.js, javascriptMVC, knockout.js, AngularJS

  * AngularJS는 구글 팀에 의해 등장하여 MVW(Model-View-Whatever)를 표방하고

    View와 Model간 양방향 바인딩, SPA, Promise/A 스펙 비동기를 지원함.

출처 : edu.goorm.io/learn/lecture/557/%ED%95%9C-%EB%88%88%EC%97%90-%EB%81%9D%EB%82%B4%EB%8A%94-node-js/lesson/174353/%EC%9E%90%EB%B0%94%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8%EC%9D%98-%EC%97%AD%EC%82%AC

용어 정의

- 컴포넌트 : 프로그래밍에 있어 재사용이 가능한 각각의 독립된 모듈.

- 컴포넌트 기반 프로그래밍 : 레고 블록처럼 이미 만들어진 컴포넌트들을 조합하여 화면을 구성.

- 웹 컴포넌트 : 컴포넌트 기반 프로그래밍을 웹에서도 적용할 수 있도록 W3C에서 새로이 정한 규격.

웹 컴포넌트 규격

- Shadow DOM : DOM과 스타일을 캡슐화하여 메인으로부터 독립적으로 스크립트와 스타일을 처리할 수 있도록 한다.

- Custom Elements : HTML에 새로운 HTML/DOM 요소를 정의할 수 있는 JavaScript API.

- HTML Templates : 문서가 처음 로드될 때는 비활성화된 상태지만, JavaScript를 사용하는 런타임에 나타나는

                           HTML 조각.

- ES Modules : 이전 규격이었던 HTML Import를 대체하여 나온 규격이며, JavaScript로 구현하는 모듈 시스템.

출처 : swimjiy.github.io/2019-05-17-js-web-component

개요

웹 페이지의 외형, 데이터 등을 사용자와의 상호작용을 통해 동적으로 변경하기 위한 스크립트 언어

특징

- JavaScript는 인터프리트 언어로 브라우저에 의해 해석 / 실행된다.

장점

- 운영체제나 플랫폼에 상관 없이 동작

- 높은 확장성

출처 : coding-factory.tistory.com/193

1. 목적

역할의 분리를 통한 유지 보수 용이성, 개발 효율의 향상

2. 종류

1) MVC(Model, View, Controller)

2) MVP(Model, View, Presenter)

3) MVVM(Model, View, View Model)

2.1. MVC

2.1.1. 동작

(1) 사용자의 Action들은 Controller에 들어온다.

(2) Controller는 사용자의 Action을 확인, Model을 갱신한다.

(3) Controller는 Model을 나타내 줄 View를 선택한다.

(4) View는 Model을 이용하여 화면을 표시한다.

2.1.2. 특징

- Controller는 여러 개의 View를 선택할 수 있는 1:n 구조이다.

- Controller는 View를 선택할 뿐, 직접 갱신하지는 않는다.(View는 Controller를 알지 못한다.)

2.1.3. 장점

- 단순하여 보편적으로 많이 사용된다.

2.1.4. 단점

- View와 Model간 의존성이 높아 App 규모가 커짐에 따라 복잡해져서 유지 보수가 어려워 진다.

2.2. MVP

* Presenter : View에서 요청한 정보로 Model을 가공하여 View에 전달해주는 부분으로

                 View와 Model을 붙여주는 접착제 역할이다.

2.2.1. 동작

(1) 사용자의 Action들은 View를 통해 들어온다.

(2) View는 데이터를 Presenter에 요청한다.

(3) Presenter는 Model에게 데이터를 요청한다.

(4) Model은 Presenter에게 요청받은 데이터를 응답한다.

(5) Presenter는 View에게 데이터를 응답한다.

(6) View는 Presenter가 응답한 데이터를 이용하여 화면을 나타낸다.

2.2.2. 특징

- Presenter는 View와 Model의 인스턴스를 가지고 있어 둘을 연결하는 접착제 역할을 한다.

- Presenter와 View는 1:1 관계이다.

2.2.3. 장점

- Presenter를 통해서만 데이터를 전달받기 때문에 View와 Model간 의존성이 없다. (MVC 패턴의 단점을 해결)

2.2.4. 단점

- View와 Presenter 사이의 의존성이 높다.

- App이 복잡해질수록 View와 Presenter 사이의 의존성이 강해진다.

2.3. MVVM

* View Model : View를 표현하기 위해 만든 View를 위한 Model이자 View를

                     나타내기 위한 데이터 처리를 하는 부분이다.

2.3.1. 동작

(1) 사용자의 Action들은 View를 통해 들어온다.

(2) View에 Action이 들어오면, Command 패턴으로 View Model에 Action을 전달한다.

(3) View Model은 Model에 데이터를 요청한다.

(4) Model은 View Model에게 요청 받은 데이터를 응답한다.

(5) View Model은 응답 받은 데이터를 가공하여 저장한다.

(6) View는 View Model과 Data Binding하여 화면을 나타낸다.

* View와 View Model은 데이터 바인딩 되어, View Model의 값이 변경될 시 View도 갱신된다.

2.3.2. 특징

- MVVM 패턴은 Command 패턴, Data Binding 패턴 두 가지를 사용하여 구현된다.

- Command 패턴과 Data Binding을 사용하여 View와 View Model 사이의 의존성을 제거했다.

- View Model과 View는 1:n 관계이다.

2.3.3. 장점

- View와 Model 사이의 의존성이 없다.

- Command 패턴과 Data Binding 패턴 덕에 View와 View Model 사이의 의존성도 없다.

- 각 부분은 독립적이기 때문에 모듈화 하여 개발할 수 있다.

2.3.4. 단점

- View Model의 설계가 쉽지 않다.

출처 : beomy.tistory.com/43

1. BOM이란?

- 브라우저와 관련된 기능을 구성하는 브라우저 객체 모델의 집합

- 최상위 객체는 window로 BOM은 window의 하위 객체

2. DOM이란?

- DO(문서 객체) : HTML TAG들을 Javascript에서 이용할 수 있는 객체로 만든 것

- DOM의 넓은 의미 : 웹 브라우저가 HTML 페이지를 인식하는 방식

- DOM의 좁은 의미 : document 객체와 관련된 객체의 집합

- 문서 객체의 생성 방식

1) 정적 생성 방식 : 웹 브라우저가 HTML 문서에 적힌 태그를 읽을 때

2) 동적 생성 방식 : 원래 HTML 페이지에 없던 문서 객체를 Javascript를 통해 생성할 때

출처 : m.blog.naver.com/magnking/220972680805

1. JavaScript Framework

1.1. 목적

자바스크립트의 구현을 쉽고 빠르게 하는 것

1.2. 개요

설계의 바탕이 되는 기반코드와 이를 커스터마이징 할 수 있는 라이브러리의 통합체이다.

1.3. 대표격

- Angular

- React

2. Angular

2.1. 목적

Single Page Application의 쉬운 작성

2.2. 개요

- 구글 지원의 오픈소스 웹 App 프레임워크

- SPA 형태의 개발

- 큰 커뮤니티

- 데이터 중심적, 테스트 주도적, 선언적 HTML

2.3. 특징

1) Two Way Data-Binding

- model과 view를 양방향으로 연결

- 한 쪽의 데이터 변경 시 양쪽 다 갱신

2) Dependency Injection

- 컴포넌트간 서비스 사용 및 의존성 관리가 용이

- 코드상 밀접한 연관이 없는 컴포넌트의 테스트가 쉬움

3) Directives

- 필요에 따라 커스텀 HTML TAG 작성, 사용 가능

3. React

3.1. 목적

데이터가 지속적으로 변화하는 대규모 APP 구축을 위해 만들어짐

3.2. 개요

- 페이스북에서 만들고 있는 자바스크립트 라이브러리

- 기존 Angular, Ember의 서버 보조 역할 탈피로 HTML5 History API등을 통해 상태별 고유 주소 구현이 가능해짐

-> 클라이언트 라이브러리 페이지가 렌더링에 관여하게 되어 검색엔진 최적화 및 성능 문제가 발생

=> 대안으로서 React가 개발됨

3.3. 특징

1) JUST the UI

- 오직 UI 컴포넌트를 만들기 위한 라이브러리

2) Virtual DOM

- DOM Tree와 같은 구조체를 Virtual DOM으로 가지고 있다.

- V-DOM은 가상의 HTML Element를 가진 상태에서 렌더링을 통해 DOM 조작 등 필요한 부분만을 갱신한다.

- 일관성이 있어 브라우저에 의존적이지 않고 테스트가 쉽다.

- 메모리 상에 DOM을 구성, 구성한 대상을 비교하여 갱신된 부분만 갱신하기 때문에 속도가 빠르다.

3) DATA Flow

- 데이터의 단방향 흐름을 지향하기 때문에 Angular처럼 코드 양이 줄지는 않는다.

- 모델 컴포넌트가 데이터를 UI 컴포넌트로 전달하기 쉬운 관리 App을 만들 수 있다.

- 이벤트를 통해 하위 컴포넌트의 변화를 감지할 수 있다.

4. Framework와 Library의 차이

4.1. Framework

4.1.1. 목적

원하는 기능 구현에만 집중한 빠른 개발을 지원

4.1.2. 개요

개발에 필요한 기능들이 어느 정도 구성된 뼈대를 제공, 개발 효율을 향상시키지만, 정해진 구조에 맞게 개발해야함

4.2. Library

4.2.1. 목적

재사용이 필요한 기능의 반복적 코드 작성 제거

4.2.2. 개요

특정 기능에 대한 API(도구/함수)의 집합 기능을 사용하기 위해 호출하는 방식

4.3. 차이점

- Library를 사용하는 AppCode는 App흐름을 직접 제어한다.

  단지 동작하는 중에 필요한 기능이 있을 때 능동적으로 라이브러리를 사용할 뿐이다.

- 반면 프레임워크는 거꾸로 AppCode가 프레임워크에 의해 사용된다.(제어의 역전)

  AppCode는 프레임워크가 짜놓은 틀에서 수동적으로 동작해야 한다.

4.4. 그 외

- Backbone.js는 Javascript의 mvc 패턴을 구현하기 위한 라이브러리

- React는 단순히 UI를 렌더링 하기 위한 라이브러리

출처

www.incodom.kr/JavaScript_%ED%94%84%EB%A0%88%EC%9E%84_%EC%9B%8C%ED%81%AC_%EC%A0%95%EC%9D%98

web-front-end.tistory.com/63

blog.gaerae.com/2016/11/what-is-library-and-framework-and-architecture-and-platform.html