그 바보 같던 Javascript가 맞냐…? 가슴이 웅장해진다…
시간이 흘러 jQuery가 등장하고, 브라우저 간 표준이 갖춰집니다. 그리고 다시 ES6로 넘어오는 과정을 거치며 단순한 스크립트 언어였던 자바스크립트는 점점 강력해졌습니다. 변수를 선언할 때 블록 스코프를 지원하지 않아(var) 시시콜콜 클로저를 만들어 사용하던 지질함에서 벗어났습니다(let, const). 콜백 함수로만 비동기를 표현하던 부조리에서 벗어나 비동기 상황을 일급 객체로(Promise)도 다룰 수 있게 되었습니다.
자바스크립트가 프로그래밍 언어로서의 구색을 갖춰가는 한편, 인터넷 망과 그 인터넷이 실행되는 클라이언트 기기의 하드웨어도 비약적으로 성능이 개선되었습니다.
2000년대 초중반쯤 아버지가 PC방을 하시던 친구 집 데스크톱에 램이 1기가나 꽃혀 있다는 소식을 듣고 거짓말 치지 말라고 했던 기억이 있는데요. 이젠 아무리 성능이 떨어지는 보급형 스마트폰 기기라도 1기가 이상은 무조건 달려 있죠. 웹에서 더 복잡하고 거대한 무언가를 만들어낼 수 있는 기반이 갖춰진 것입니다.
렉줄이기 팁 (2006-08-19) https://www.inven.co.kr/board/wow/17/1290
SPA(Single Page Application)과 CSR(Client-side Rendering)은 그러한 발전상에 그려진 굵직한 한 꼭지입니다. 지금까지는 서버에서 HTML을 주는대로 덥석덥석 그려댔지만 자바스크립트로 할 수 있는게 많아지자, 개발자들은 산에 올라보기로 합니다. 서버에서는 최소한의 HTML을 한번만 받고, 나머지 화면을 전부 자바스크립트로만 그리기로 한 것이죠.
이제부터 적어도 웹 애플리케이션의 View단 만큼은 최초 로딩 후 서버와 완벽히 분리되었습니다. 프론트엔드와 백엔드가 구분되기 시작한 것입니다.
언제나 중요한건 Why? 입니다.
앞서 우리는 MPA의 라우팅 방식을 살펴보면서 새 술은 새 부대에 담듯, 새로운 화면은 새로운 HTML에 담아 보여줬습니다. 하지만 물 마실 때마다 매번 머그컵을 내다버린다면 얼마나 큰 낭비일까요? 컵은 그대로 두고 정수기에서 물만 다시 채워서 먹는 방법이 더 효과적입니다.
새로운 화면을 보기 위해 HTML을 새로 받아오면 무조건 1) 전체 화면이 하얗게 날아가고 → 2) 서버와 통신하여 새로운 HTML을 받아온 뒤 → 3) HTML 문서가 로딩되면 문서 안에서 보여줘야 하는 사진, 동영상 등의 콘텐츠를 다운로드 하는 절차를 거쳐야 했습니다.
하지만 이제는 화면을 바꾸는데 필요한 데이터만 API 호출을 통해 JSON 객체로 받아온 뒤(fetch), 해당 부분의 데이터만 갈아끼우는 방식(querySelector, innerHTML)으로 화면을 만들 수 있게 되었습니다. 하나의 HTML 만을 가지고도 다채로운 화면을 그릴 수 있다면 앞서 언급했던 불필요한 통신으로 인한 오버헤드를 줄일 수 있겠네요.
1) 브라우저에서 서버로 웹 페이지를 조회하고 싶다는 요청을 보낸다.
2) 서버는 브라우저로부터 날아온 요청 경로를 확인(/)하고 index.html 을 서버 내 자원으로부터 찾아 응답으로 돌려준다. 이 때 index.html의 body 태그 내부는 비어있는 상태다.
3) 브라우저는 HTML 파일에서 head 태그를 읽으며 추가로 필요한 자원(index.js, index.css 등)을 서버로 다시 요청한다.
