Wanna be a thinker

■HTML 연대표

■배경 지식

1. HTML(Hyper Text Markup Language)

- HyperText(다른 페이지로 이동할 수 있도록 하는 링크가 달린 텍스트) 기능을 가진 문서를 만드는 언어이다.

- Markup언어는 문서를 <>태그로 표현하는 문서 작성 형식이며, HTML은 SGML을 계승했다.

2. 웹 페이지(Web Page)

- www(World Wide Web)상에 있는 개개의 문서를 의미한다.

- HTML은 .htm, .html의 확장자를 가지며, 웹 브라우저가 <>태그의 구조를 해석하여 화면에 표현한 것이 웹 페이지다.

3. www(World Wide Web)

- 인터넷에 연결된 컴퓨터들을 통해 사람들이 정보를 공유할 수 있는 전 세계적인 정보 공간을 의미한다.

- 간단히 웹(Web)이라고 부르는 경우가 많다.

- 웹과 인터넷은 동의어가 아니다. (인터넷은 모든 컴퓨터를 하나의 통신망에 연결(Inter Network)하고자 하는 의도에서 이를 줄여 InterNet이라고 명명한 것에 어원을 두고 있다.)

4. W3C(World Wide Web Consortium)

- www를 위한 표준을 개발하고 장려하는 조직으로 회원기구, 정직원, 공공기관이 협력하여 웹 표준을 개발한다.

5. 시멘틱 마크업(Semantic Markup)

- 종종 POSH(Plain Old Semantic HTML)라고도 불리며, 평범하고 오래된 의미론적인 HTML이라는 뜻이다.

- HTML은 문서의 콘텐츠 정보를 설명하는데 사용되는 마크업 언어이므로 그 역할에 집중하는 것이다.

- 적절한 HTML 요소를 올바르게 사용하는 것에서 시작한다.

ex) 웹 사이트의 제목은 <title> 태그를 사용하는 것.

■HTML의 등장 배경

- '유럽 핵입자 물리 연구소'에 근무하던 '팀 버너스 리'가 기존의 'SGML(Standard Generalized Markup Language)'에

<a> 태그(하이퍼 링크 시스템)를 추가한 언어가 'HTML(HyperText Markup Language)'이다.

- 연구자들의 자료, 논문을 하이퍼링크 기술을 통해 손쉽게 참조하려는 목적이 아니었을까 유추해본다.

■HTML 1.0 등장

- 텍스트 위주의 정보전달 목적으로 사용되었다.

■W3C(World Wide Web Consortium) 등장

- 팀 버너스 리를 중심으로 한 웹의 표준을 정의하는 국제 기구이다.

- HTML 사용자 증가에 따라 문서가 다양한 브라우저에서 동일하게 표현되기 위한 표준을 정의한다.

■HTML 2.0 ~ 3.2

- 당시 각 브라우저들은 표준화되어 있지 않아 브라우저마다 표현되는 태그가 각기 달랐다.

- www 일반 사용자가 증가하고, 사용자는 더 많은 정보를 표현하기를 원했다.

- 웹의 열풍으로 다양한 브라우저가 보편화되어 공통적으로 태그를 표현할 수 있도록 표준 정의에 관심을 가진다.

■HTML 4.01

- 'CSS(Cascading Style Sheet)'가 등장하여 디자인적인 요소를 구분하고, HTML은 문서의 구조만 명시할 수 있게 되었다.

- 정보와 디자인을 구분하여 생각한 것이다.

■XHTML 1.0

- W3C는 XML과 HTML을 합성, 태그를 확장하고 엄격한 문법 검사를 적용한 새로운 표준인 XHTML을 만들었다.

- 단, XML은 버전과 버전사이의 하위 호환성을 지원하지 않아서 이전의 태그들로 작성된 문서가 표현되지 않는 문제와 문법의 엄격함에 따른 높은 진입장벽으로 인해 사용자가 등을 돌렸다.

* 'XML(eXtensible Markup Language)'

  - W3C에서 개발된, 다른 특수한 목적을 갖는 마크업 언어를 만드는데 사용하도록 권장하는 다목적 마크업 언어이다.

  - XML은 SGML의 단순화된 부분 집합으로, 더 많은 종류의 데이터를 기술하는 데 사용할 수 있다.

  - XML은 주로 다른 종류의 시스템, 특히 인터넷과 연결된 시스템끼리 데이터를 쉽게 주고 받을 수 있게 하여 HTML의    한계를 극복할 목적으로 만들어졌다.

■WHATWG(Web Hypertext Application Technology Working Group)

- W3C가 XHTML을 표준으로 삼으려는 움직임에 대항하여 기업들이 HTML을 계승하는 자신들만의 표준을 만든다.

- 이는 HTML5의 시초가 된다.

■HTML5

- W3C도 XHTML을 표준에서 탈락시키고 WHATWG에서 정의한 표준을 따르기로 한다.

- HTML5와 CSS가 표준으로 확정되고, 지금의 HTML 표준이 완성된다.

출처

hyoje420.tistory.com/22

webclub.tistory.com/608

■Node.js

1. 개요
- 서버 환경에서 동작하는 자바스크립트 프레임워크로 DB-클라이언트-서버를 모두 자바스크립트로 구성할 수 있게 되었다.

2. 등장 배경
- 자바스크립트 활용도의 증가
- 웹 브라우저를 벗어나 사용하려는 움직임이 시작
- 2008/9~ 구글 크롬 발표, V8 자바스크립트 엔진의 등장, 자바스크립트의 단점인 '속도'가 개선, 코드를 공개
- 2009/1~ 자바스크립트를 웹 브라우저 외에서 사용하기 위한 표준을 만들자는 의견 증가로 CommonJS 표준 발표

- Ryan Dahl은 CommonJS 표준과 V8 자바스크립트 엔진을 기반으로 Node.js를 개발

3. 기존 어플리케이션과 Node.js 어플리케이션의 차이

- 기존 웹 서버는 대부분 스레드를 기반으로 하는 동기 방식으로 네트워크 입출력을 처리

- Node.js는 이벤트를 기반으로 하는 비동기 방식으로 네트워크 입출력을 처리

4. 이벤트 기반 비동기 방식이란?
예) 재래 시장에서 4개의 가게를 들러 장을 보는 상황이다.
- 동기 방식(멀티 스레드, 멀티 프로세스)
: 몸을 복제해 동시에 여러 가게에 가서 줄을 선다.
- 비동기 방식(이벤트 기반)
: 시장에 대기 시스템을 도입 후, 각 가게를 돌면서 대기표를 받고, 번호가 불리면(이벤트 발생) 물건을 받아온다.

- 동기 방식은 작업 요청이 들어올 때마다 스레드를 여러 개 만들어 동시에 일을 처리한다.
  일과 스레드의 양은 비례하므로 메모리 사용량이 증가한다는 단점이 있다.

- Node.js가 사용하는 '이벤트 기반 비동기 방식'은 스레드를 단 하나만 생성하므로 몸은 하나이고, 이벤트를 사용하므로
  빠르게 일을 처리할 수 있다. 일은 많아도 어쨋든 몸은 하나이므로 메모리 사용량과 같은 시스템 리소스 사용량에는 변화가 거의 없다.
  따라서 대규모 네트워크 프로그램을 개발하기 적합한 형태이다.
  단점은, 그 한명이 쓰러지는 순간 프로그램 전체에 문제가 발생한다.

  * Node.js 내부는 여러 스레드가 스레드 풀로 동작한다. 또한 실제 웹서버를 운용할 때에는 코어를 분산해서

    관리하므로 하나의 스레드만 사용한다고 볼 수 없다. 중요한 것은 스레드의 운용을 플랫폼이 담당하며, 

    개발자는 스레드를 의식하지 않고 프로그래밍을 할 수 있다는 점이다.

5. Node.js의 장단점

- 장점
  1) 자바스크립트를 사용하기 때문에 웹 개발자의 진입 장벽이 낮다.
  2) 구글의 V8 자바스크립트 엔진을 사용하기 때문에 앞으로도 계속 성능 개선의 여지가 있다.
  3) C++을 이용한 기능 확장이 가능하다.
  4) 'Non-blocking I/O'와 '단일 스레드 이벤트 루프'를 통한 높은 Request 처리 성능을 가지고 있다.
      DB에서 대량의 데이터를 취득, 웹페이지에 표시하는 처리의 경우, 일반적으로 DB 처리에 대기시간(blocking)이 

      발생하기 때문에 웹페이지 표시가 지연되는 현상이 발생한다.
      'Non-blocking I/O'는 비동기 처리를 실시하므로 DB 처리와 웹페이지 표시를 별도 진행하여 

      스트레스 없이 웹페이지 표시가 가능하다.

  5) Node.js에는 Socketio라는 실시간 통신을 실현하는 라이브러리가 있어 대량의 데이터 처리와 실시간 통신을 

     구현할 수 있는 기능을 모두 갖추고 있다.

- 단점
  1) 자바스크립트를 사용하기 때문에 C나 C++로 개발된 서버 어플리케이션보다 느리다.

출처 : zbulletjournal.tistory.com/85

■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