2.1 자바스크립트의 탄생
- 1995년, 넷스케이프는 웹페이지의 보저적인 기능을 수행하기 위해 브라우저에서 동작하는 경량 프로그래밍 언어 도입하기로 결정하고, 브렌던 아이크(Brendan Eich)에 의해 개발
- 1996년, "모카(Mocha)"로 명명 후 "라이브스크립트(LiveScript)를 거쳐 "자바스크립트(JavaScript)로 최종 명명 됨
2.2 자바스크립트의 표준화
- 1996년, 마이크로소프트는 "JScript"를 출시
- 마이크로소프트와 넷스케이프의 경쟁으로 브라우저에 따라 웹페이지가 정상적으로 동작하지 않는 크로스 브라우징 이슈가 발생
- 이에따라 표준화된 자바스크립트의 필요성이 대두됨
- 1997년, ECMA-262라 불리는 표준화된 자바스크립트 초판 사양이 완성되었고, 상표권 문제로 자바스크립트는 ECMScript로 명명되었음
- 이후 여러 변화를 거쳐, 2015년 공개된 ECMAScript 6(ES6)는 let/const 키워드, 화살표 함수 등과 같이 범용 프로그래밍 언어로서 갖춰야할 기능들을 대거 도입하는 큰 변화가 있었다.
- ES6 이후의 버전업은 비교적 작은 기능을 추가하는 수준으로 매년 공개할 것으로 예고되었다. (2020년 기준, ES11까지 발표)
😳ES6, ES6 말만 많이 했지, 가장 최신버전도 아닌데 왜 하필 6인지 몰랐는데 이제야 이해가 됐다.2.3 자바스크립트 성장의 역사
초창기 자바스크립트는 웹페이지의 보조적인 기능을 수행하기 위해 한정적인 용도로 사용되었다. 이 시기에 대부분의 로직은 주로 웹 서버에서 실행되었고, 브라우저는 서버로부터 전달받은 HTMl과 CSS를 단순히 렌더링하는 수준이었다.
2.3.1 Ajax
- 1999년, 비동기 방식으로 데이터를 교호나할 수 있는 통신 기능인 Ajax(Asynchronous JavaScript and XML)가 XMLHttpRequest라는 이름으로 등장했다.
- Ajax의 등장으로 변경해야 하는 부분만 한정적으로 렌더링하는 방식이 가능해졌음
2.3.2 jQuery
- 2006년, jQuery의 등장으로 다소 번거롭고 논란이 있던 DOM(Document Object Model)을 더욱 쉽게 제어할수 있게 되었고, 크로스 브라우징 이슈도 어느 정도 해결되었다.
2.3.3 V8 자바스크립트 엔진
- 2008년, 더욱 빠르게 동작하는 자바스크립트 엔진의 필요성 대두에 의해 구글의 V8 자바스크립트 엔진이 등장
- 이에 따라 촉발된 자바스크립트의 발전으로, 과거 웹 서버에서 수행되던 로직들이 클라이언트로 이동했고, 이는 웹 애플리케이션 개발에서 프론트엔드 영역이 주목받는 계기로 작용했다.
2.3.4 Node.js
- 2009년, 라이언 달(Ryan Dahl)이 발표한 Node.js는 구글 V8 자바스크립트 엔진으로 빌드된 자바스크립트 런타임 환경이다.
- Node.js는 브라우저의 자바스크립트 엔진에서만 동작하던 자바스크립트를 브라우저 이외의 환경에서도 동작할 수 있도록 자바스크립트 엔진을 브라우저에서 독립시킨 자바스크립트 실행 환경이다.
- Node.js는 비동기 I/O를 지원하며 단일 스레드 이벤트 루프 기반으로 동작함으로써 요청 처리 성능이 좋다. 따라서 SPA에 적합하며, CPU 사용률이 높은 애플리케이션에는 권장하지 않는다.
2.3.5 SPA 프레임워크
- 모던 웹 애플리케이션의 개발규모와 복잡도의 상승으로, 필연적으로 프레임워크가 등장하게 되었다.
- 이러한 요구에 발맞춰 CBD(Component based development)방법론을 기반으로 하는 SPA(Single Page Application)가 대중화되면서 Angular, React, Vue.js, Svelte 등 다양한 SPA 프레임웤/라이브러리 또한 많은 사용층을 확보하고 있다.
2.4 자바스크립트와 ECMAScript
- 자바스크립트는 일반적으로 프로그래밍 언어로서 기본 뼈대를 이루는 ECMAScript와 브라우저가 별도 지원하는 클라이언트 사이드 Web API, 즉 DOM, BOM, Canvas, fetch 등을 아우르는 개념이다.
2.5 자바스크립트의 특징
- HTML, CSS와 함께 웹을 구성하는 요소 중 하나로 웹 브라우저에서 동작하는 유일한 프로그래밍 언어
- 개발자가 별도의 컴파일 작업을 수행하지 않는 인터프리터 언어
- 명령형, 함수형, 프로토타입 기반 객체지향 프로그래밍을 지원하는 멀티 패러다임 프로그래밍 언어
다른 객체지향 언어와의 차이점에 대한 논쟁이 있지만,클래스 기반 객체지향 언어보다 효율적이면서 강력한 프로토타입 기반의 객체지향 언어다.
2.6 ES6 브라우저 지원 현황
- 인터넷 익스플로러를 제외한 모던 브라우저의 ES6 지원 비율은 96~99%로 거의 100%에 육박하지만, 인터넷 익스플로러나 구형 브라우저는 ES6를 대부분 지원하지 않는다.
- 따라서, ES6를 지원하지 않는 환경이라면, 바벨과 같은 트랜스파일러를 사용해 ES5이하의 사양으로 다운그레이드할 필요가 있다.
Babel이나 Webpack을 깊게 공부하기전이지만, 저렇게까지 모든 케이스에 맞춰 개발할 필요가 있을까?
지난 프로젝트에서 1차 릴리즈 후, 접속 환경에 따라 사용자 경험이 달라 고생했던 기억이 난다.(앱 개발이 아니라 웹+반응형이라 어느정도 감수해야하는 부분이었지만..)
모바일 기기별, 브라우저별로 각기 대응이 필요했는데 그중에서도 특정 브라우저에서 문제가 많이 발생하여 개발할수록 그라데이션 분노가 차올랐었다.
99%의 문제는 해결했지만 나머지 1%의 작은 문제는 시간과 비용상의 문제로 남겨두기로 하고 프로젝트는 마무리되었다.
심지어 남은 1%를 해결하기위한 방안으로 문제가 되는 코드를 다운그레이드하자는 말까지 나왔었다. 비용과 시간, 기술 등을 모두 고려하여 적절히 범용성 있는 개발을 해내는 것도 중요한 개발 포인트인것 같다.
백엔드의 경우는 어떤 케이스가 있는지 경험해보지 못했지만, 프론트는 특히나 눈에 보이는 요소들이기 때문에 더 중요한 포인트인것같다. 이 주제에 대해 쓰다보니 할말이 너무 많아서 다음에 제대로 각잡고 글을 써봐야할 것같다. 지금도 할말이 자꾸 생각나지만 이쯤에서 줄이고 딥다이브나 계속해서 읽어야겠다.
FE Developer