오늘 한 것

JavaScript

1995년 웹페이지의 보조적인 기능을 수행(웹서버 실행, HTML/CSS 랜더링 등)하기 위한 브라우저에서 동작하는 경량 프로그래밍 언어로 탄생하였다.
처음 이름은 ‘모카’에서 ‘라이브스크립트’로 변경했다가 1996년 12월 최종적으로 ‘JavaScript’로 명명되었다.
1996년 8월 마이크로소프트의 JScript가 IE 3.0에 탑재되면서 JavaScript와의 표준화에 실패하고 자사 브라우저 사장 점유율 높이려고 치킨게임을 시작했고 이로 인해 크로스 브라우징 이슈가 끝없이 발생했다.
1996년 11월 모든 브라우저 정상 작동을 위한 ECMA 인터내셔널에 JavaScript의 표준화를 요청하며 1997년 7월 ECMA-262라는 JavaScript 초판(ECMAScript 1)사양이 완성되었고, 1999년 ECMAScript3, 2009년 ECMAScript5가 HTML5와 함께 출현하며 표준 사양이 되었다.
2015년 출시한 ECMAScript 6에는 화살표 함수, 클래스, 모듈 같은 범용 프로그래밍 언어에 적합한 기능들이 추가되며 큰 변화가 생겼다.
현재 JavaScript는 모든 브라우저의 표준 프로그래밍 언어가 되었다.
ECMAScript 2020가 현재 표준 사양이다. javaScript에 대한 표준이다. 브라우저에서 지원하는 alert() 같은 함수는 포함되지 않는 브라우저 node.js에서 모두 동작하는 순수한 엔진에 대한 표준이다.

1999년, 자바스크립트를 이용해 서버와 브라우저가 비동기(asynchronous) 방식으로 데이터를 교환할 수 있는 통신 기능인 Ajax(Asynchronous Javascript And XML)가 등장했다.
비동기통신 발명 이전에는 완전한 HTML 코드 자체를 서버로부터 받아 웹페이지 전체를 랜더링하고 이후 화면 전환이 필요하면 다시 완전한 HTML 코드 자체를 받아 웹페이지 전체를 새로 랜더링했다.
위와 같은 방식으로 랜더링을 하게 되면 변경할 필요가 없는 부분까지 전송 받아 다시 랜더링했기 때문에 불필요한 데이터 통신이 발생하였고 이로 인해 화면 전환 시 화면이 깜빡거리는 현상이 발생한다. 하지만 이는 어쩔 수 없는 웹페이지의 한계로 받아들여졌었다.
Ajax는 웹페이지에서 화면전환이 필요한 부분만 서버로부터 받아 부분만 랜더링하는 방식이다. 이로서 빠른 성능과 부드러운 화면 전환이 가능해졌다.

2008년 웹 애플리케이션을 구축하려는 요구에 부합하는 빠른 성능을 가진 구글의 V8 JavaScript 엔진이 등장했다.
V8 엔진은 JavaScript로 데스크톱 애플리케이션과 유사한 UX를 제공할 수 있는 가능성을 보여주며 웹 애플리케이션 프로그래밍 언어로 정착하였다.

node.js는 2009년 브라우저의 JavaScript 엔진에서만 동작하던 JavaScript 이외의 환경에서도 동작할 수 있도록 독립시킨 JavaScript 실행 환경이다.
JavaScript는 Node.js를 통해 서버 사이드 애플리케이션 개발에서도 사용할 수 있는 범용 프로그래밍 언어가 되었다. JavaScript는 프런트엔드 영역은 물론 백엔드 영역까지 아우르는 웹 프로그래밍 언어의 표준으로 자리 잡고 있다.

SPA는 한번의 전체 페이지 로드 이후에는 데이터 요청만으로 부분을 변경하여 사용하는 Application을 뜻한다.
언뜻보면 Ajax 같은 비동기 방식과의 다른점을 찾아 볼 수 없지만 ‘라우팅’이란 개념으로 다르게 된다. 기존 Ajax의 경우 화면을 구성해도 동일한 페이지에서 구성했기 때문에 히스토리가 남지 않고 뒤로가기나 해당 페이지 즐겨찾기가 불가능하다. 하지만 ‘라우팅’을 이용하는 SPA는 index#menu1#submenu1 같이 해쉬태그와 해쉬값에 맞는 페이지를 실행하기 때문에 한페이지 내에서 여러 페이지 구성이 가능하다.
SPA가 대중화되면서 Angular, React, Vue.js, Svelte 등 다양한 SPA 프레임워크/라이브러리가 많이 사용되고 있다.
하지만 초기 구동 속도가 상대적으로 느리며 SEO(검색최적화)에 취약한 것이 단점이다.

프로그래밍 언어에는 interpreter 언어와 compile 언어가 있다.
참고로 자바스크립트 엔진은 원래 interpreter 언어지만 일부 소스 코드는 컴파일하고 실행한다. 두 언어의 장점을 결합해 비교적 처리 속도가 느린 인터프리터의 단점을 해결했다.
현재는 컴파일러와 인터프리터의 기술적 구분이 점차 모호해져 가는 추세다.

interpreter 언어는 코드가 실행되는 단계인 런타임에 문 단위로 바이트코드(가상 머신에서 실행하도록 만드는 바이너리 코드)로 변환 후 실행한다.
위와 같은 이유로 실행 파일이 생성되지 않는다. 때문에 코드가 실행될 때마다 인터프리트 과정이 반복 수행된다.
언어 특징 때문에 실행 중 에러 발생 시 더 이상 실행이 이뤄지지 않는다.
구문에 대한 해석과 실행이 동시에 이뤄지기 때문에 별도의 실행파일이 존재하지 않는다.
컴파일이 없기 때문에 신속하게 동작한다.
대표적으로 HTML, CSS, JavaScript, Python 등이 있다.

compile 언어는 interpreter 언어와 다르게 소스코드를 전부 해석하고 수집한 후 머신 코드(CPU가 바로 실행할 수 있는 기계어)로 재구성하여 실행한다.
실행 파일이 생성된다. 때문에 컴파일은 실행에 앞서 단 한번만 수행된다.
전체 코드를 변환 후 에러를 보고한다. 이렇기 때문에 보안측에서는 interpreter 언어보다 취약하다.
컴파일 언어는 한번 컴파일하게 되면 실행 파일이 생성되며 실행파일은 interpreter 언어보다 빠르다.
대표적으로 C, C++, JAVA 등이 있다.

픽셀은 viewport에서 표현 가능한 최소 단위이다. 픽셀은 그렇다면 절대 단위인가?
하지만 같은 최대 해상도(픽셀 수가 척도인 출력 정도)를 가진 다른 크기의 디바이스 1px의 값의 절대적인 수치는 다르다. 다르게 말하면 픽셀은 디바이스 해상도에 따라 상대적인 크기를 갖는다.
1픽셀은 모든 디바이스에서 1픽셀이지만 디바이스마다 갖는 1픽셀의 크기는 다르다.
모니터의 1px과 빔프로젝트로 보는 1px을 생각하면 감이 잡힐지 모른다. 모니터에서 10px 크기의 상자와 모니터와 연결된 빔프로젝트로 보는 10px 크기의 상자는 분명 다를 것이다.
위처럼 디바이스 별로 픽셀의 크기는 제각각이기 때문에 픽셀을 기준으로 하는 단위는 명확하지 않다. 따라서 대부분의 브라우저는 1px을 1/96 인치의 절대단위로 인식한다.