1. SSR vs CSR
SSR
-
서버사이드 랜더링이란 서버에서 랜더링의 책임을 지는 방식을 말한다
-
보내지는 html의 내용에 초기랜더링에 필요한 정보가 충분히 존재하는지 안하는지가 SSR과 CSR의 차이를 만들어낸다
-
SSR은 초기에 서버로부터 필요한 페이지의 내용이 다 담긴 html을 받게된다. ( 다 담겨있다 함은, 말 그대로 header, main, aside, footer 등등)
-
해당 2진수로 이루어진 html text 응답을 받은 브라우저는 응답 헤더에 담긴 content-type과, charset을 통해 이것을 html 문서로 파싱한다
-
이미 html에 초기 화면에 대한 레이아웃을 위한 노드들이 다 들어있기 때문에 브라우저에 그대로 페인팅을 할 수가 있다.
-
그 후, script 태그를 만나면 태그에 있는 src 주소를 통해 서버에 js파일을 요청하고, 이것을 응답받으면 interaction이 가능해진다
-
html에 필요한 정보들이 다 들어가 있는 상태로 응답받기 때문에, 전통적인 서치엔진(SEO) 이 이를 읽고 분석하기가 용이했다
-
예전에 SSR 의 가장 큰 단점이라면 이렇게 페이지마다 전환이 되야 할 때 html을 항상 전달받아야 했으므로 고질적인 "깜빡임" 현상을 피해갈 수가 없었다( 새로 서버로부터 html을 전달받아 리플로우와 리페인팅을 하는 과정 사이에서 발생하는 로딩 갭 )
-
하지만 지금은 next js와 같이 서버사이드 랜더링과 더불어 클라이언트측에서도 랜더링을 일정부분 담당하게 하는 기술들이 많이 나오게 되면서 SSR과 CSR의 장점을 같이 가져가는 형태로 발전하고 있다.
CSR
-
클라이언트사이드 렌더링이란 랜더링 책임이 클라이언트에게 있는 방식을 말한다
-
DOM을 자바스크립트로 수정이 가능하다는 부분을 이용, 모든 페이지 전환을 자바스크립트로 처리하는 방식이다
-
초기에는 서버사이드 랜더링과 마찬가지로 html에 대한 2진수 응답을 서버로부터 전달받는것은 동일하다.
-
하지만 그 안에 내용물에는, 정확하게 말하면 body 부분은 비워져있고 이 내용물을 채우는 행위를 자바스크립트로 하게된다
-
즉, html 파일을 파싱하면서 script 태그를 만나게 되는 순간, 서버로부터 js 파일을 요청하여 전달받는것은 SSR와 마찬가지로 동일하다
-
그런데 이 자바스크립트 파일에는 모든 페이지를 랜더링하는 코드가 들어있다.
-
따라서, 초기에 화면이 랜더링이 되기 위해서는 이 자바스크립트 파일이 모두 읽혀져서 DOM을 조작하여 리플로우와 리페인팅이 진행되기 전까지는 보여지지 않는다
-
이말인 즉슨, 초기 화면의 랜더링 시간이 SSR보다 늦어지게 된다는 의미가 된다.
-
하지만 한번 응답을 받게 되면 그 이후로는 모든 랜더링을 자바스크립트로 처리하고 필요한 데이터베이스 정보는 AJAX 요청을 통해 서버로부터 응답받아 업데이트하는 방식을 사용하므로, 사용자 경험에 있어서 유리하다는 점이 있다.
-
다만 초기 화면 렌더링이 오롯이 자바스크립트를 응답받고 파싱하는 시간에 달려있으므로, 만약 사용자의 인터넷 환경이 느리거나 컴퓨터 성능이 좋지 않다면 초기 화면이 보여지기 전까지 상당히 오랜시간 하얀화면을 보게 될 수도 있다.
var vs let vs const
-
우선 var과 (let, const) 는 서로 스코프적으로 큰 차이를 보인다
-
스코프란 식별자를 탐색하기 위한 바운더리를 뜻한다
-
모든 식별자는 자신이 선언이 된 위치에 의하여 다른 코드가 자신을 참조할 수 있는 유효 범위(스코프) 가 결정된다.
var
-
var의 스코프는 함수스코프를 따른다. 따라서, 함수 안에 존재한다면 외부에는 해당 var 의 식별자를 통해 접근을 할 수가 없다.
-
하지만, var은 블록스코프를 따르지 않는다. ( 예를들면 if문의 블록, for문의 블록 )
-
이 말인 즉슨, 전역에서 정의된 var의 식별자와 블록스코프의 안에 정의된 var 식별자는 서로 같은 스코프 안에 있는것과 다름없이 해석된다
-
따라서 덮어씌워지는 상황이 나타날 수 있다
var i = 10;
for (var i = 0; i < 5; i++){}
console.log(i) // 5- 또한, var은 스크립트가 읽혀시면서 실행 컨텍스트가 생성되는 과정 가운데 변수들을 정의하는데, 이때 마치 자신만은 런타임이 일어난 것처럼 암묵적으로 undefined가 할당된다.
- 이 말인 즉슨, 해당 값이 할당이 완료되기 전에 이미 정의가 완료된 상태가 되어버리므로 "호이스팅" 이 가능해진다
console.log(hoisting); // undefined
var hoisting;- 이런식의 호이스팅은 코딩에 있어 변칙과 혼란을 야기하므로 지양해야한다. (즉, var 자체를 지양해야한다)
let, const
- 이와 다르게 let과 const는 블록레벨 스코프를 지원한다
- 또한 스크립트가 읽혀가며 실행 컨텍스트를 만들어가는 도중, 변수를 선언하는 과정에서는 아직 할당까지는 일어나지 않는다
- 즉, 초기화가 되지 않고 식별자만 정의된 상태가 된다 ( 메모리 공간을 확보하고 거기에 네이밍만 한 상태 )
- 이 상황에서 호이스팅과 같이 할당이 되지 않았음에도 먼저 참조하는 방식을 시도하려고 한다면 레퍼런스 에러를 만든다
- 이를 일시적 사각지대 (TDZ) 이라고 한다.
console.log(hoisting) // ReferrenceError : hoisting is not defined
let hoisting;- 또한 const는 여기서 let과는 다르게 재할당이 불가능하다.
- 재할당이 불가능하다 함은, 이미 한번 위에서 정의된 상태라면 그 할당 내용을 다른것으로 바꿀 수 없다는 것을 의미한다
- 할당이란 확보된 메모리 공간 안에 내용물을 채워넣는 과정이다.
- 다시말해서 const는 한번 확보된 메모리 공간 내의 값을 변경할 수 없다는 것을 의미한다
- 또한, AST를 형성하는 과정 가운데, const는 declaration으로 분류되는데, 여기서 할당에 대한 initializer가 존재하지 않는다면 에러를 만든다.
const foo; // SyntaxError : Missing initializer in const declaration;
const bar = 1;
bar = 2; // TypeError : Assignment to constant variable