자바스크립트의 또다른 이름들
Mocha -> LiveScript -> ECMAScript -> Javascript -> ES6 -> ...
기술의 빠른 속도와 그것을 도입하는데 걸리는 시간적 차이에 의해 발생한 또다른 기술
개발자들은 자신들이 원하는 언어와 최신문법으로 개발을 사용하고 싶은 필요성을 느낌에 따라 개발된 것이 Transfiler라는 것이다. 브라우저는 언어가 변화하는 속도에 맞추어 지원할 수 있는 환경을 제공할 수 없기에 등장한 기술이다. 그렇게 최신 자바스크립트 언어를 구버전으로 변환시켜 여러 브라우저에서 안정적으로 동작할 수 있게끔 변환시키는 대표적인 Transfiler가 바로 Babel이다. Typescript도 Transfiler의 일종이다.
화면이 브라우저에 표시되기까지 거치는 단계들
사용자가 브라우저에 주소를 입력하게 되면 파일들이 브라우저에 물리적으로 전송된다. 브라우저는 그 파일을 해석해서 페이지를 만들어주는데 이를 렌더링이라고 한다. 페이지 뿐만 아니라 웹 어플리케이션은 브라우저를 통해 실행된다. 실행되는 환경을 런타임 환경이라고 한다. nodejs가 나타나기 이전 브라우저만이 자바스크립트의 유일한 실행 환경이었는데 Nodejs가 나오면서 실행환경이 추가되었다.
UI를 만들기 위해선 HTML이 필수다. HTML은 웹서버가 브라우저에 HTML파일을 전송해주면서 만들어진다. 그 말인 즉슨 웹서버에 HTML 파일이 존재한다.
웹서버에서 브라우저에게 HTML 파일을 전송한 이후 Javascript로 HTML 파일을 조작할 것이 있으면 조작하게 된다. 이렇게 Javascript를 이용해서 UI를 주도적으로 변경하는 것을 CSR; 클라이언트 사이드렌더링이라고 한다.
이와는 다르게 웹서버에서 주도적으로 만들어서 브라우저한테 전송하는 방법은 SSR; 서버 사이드 렌더링이라고 한다.
어떤 어플리케이션이든 CSR 또는 SSR 방식으로 개발을 할 수 있다. 어플리케이션 특성에 따라 렌더링 방식을 달리해서 프로그램밍 하면 된다.
프론트엔드 영역은 그래픽적인 요소를 다룰 수 있는 분야이기도 하기 때문에 그래픽 관련한 작업에 대해서 후에 추가로 공부를 실시하거나 할 수 있다.
프론트엔드의 개발환경이 복잡한 이유와 그럴 수 밖에 없는 이유
웹앱의 규모가 커지고 복잡해지는 것과 관련이 있다. 앱의 규모가 커진다는 것은 앱을 이루고 있는 파일의 수가 많다는 것이고 수십만 줄의 코드들로 작성되어졌다는 것을 의미한다. nodejs와 npm 이전 자바스크립트를 작동시키기 위해선 브라우저 환경에서만 자바스크립트 파일을 실행할 수 있었고 HTML 문서 안에 스크립트 파일을 적어주어야했다.
따라서 여러개의 자바스크립트 파일을 만들게 될 경우 어느 한 파일에서 특정 파일의 기능을 이용해야 하는 경우 import와 export를 이용해야 한다. 웹앱의 규모가 커지면서 이러한 부분에는 한계가 있었다. 이후 nodejs가 발명이 되면서 브라우저 환경이외의 환경에서 자바스크립트가 돌아갈 수 있게 되었고 npm이 나오면서 필요한 앱을 설치해서 쓸 수 있는 환경이 만들어지게 되었다. 그 중 번들러라는 앱을 통해 여러개의 자바스크립트 파일을 하나의 파일로 만들어서 HTML 문서 내부에 이식시킬 수 있게 되었다.
이와 더불어 자연스럽게 어떻게 하면 불필요한 코드들을 줄일 수 있을까에 대한 고민 보여지는 자바스크립트를 코드를 보이게 어렵게 함으로써 보안적인 고민 등등은 여러가지의 기능들이 추가되는 양상을 만들게 되었고 그런 이유로 점점 많은 것들이 추가됨에 따라 번들러에는 계속해서 기능들이 추가되었다. 이에 사용방법과 세팅하는 방법이 복잡해지게 되었다.
결론
규모가 큰 애플리케이션을 개발함에 따라 여러가지 기술이 등장함으로써 기술적 한계를 극복하는 측면에서 긍정적이면서도 개발자입장에서 배워야 하는 부분이 늘어나게 되므로 마냥 기뻐할 수 만은 또 없다.
