node.js 에는 JS 엔진이 있어서
브라우저 없이도 JS를 실행할 수 있다.
index.html을 만들어서 main.js를 연결한다.
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Document</title>
<script src="main.js"></script>
</head>
<body>
</body>
</html>이 파일을 라이브 서버를 열고, 콘솔창을 연다.
node.js와 웹 API 둘 다
콘솔에 관련된 API가 있다.
그리고 이 두 API들의 인터페이스가 동일하다.
https://developer.mozilla.org/ko/docs/Web/API/Console_API
Console API
Console API는 코드의 특정 지점에서 값이나 변수를 기록하고, 작업의 소요 시간을 알아내는 등 개발자가 사용할 수 있는 디버깅 기능을 제공합니다.
developer.mozilla.org
Web API 중 하나이다.
Applicaition
Programming
Interface
Web APIs는 JS 언어 자체에 포함된 아이가 아니라,
브라우저가 제공하는, 브라우저가 이해할 수 있는 함수들이다.
여기서 Console API 명세를 누르면
함수들은 어떤 것들이 있고,
어떤 데이터를 어떤 파라미터 형태로 전달해야 하는지 써있다.
point: 콘솔은 언어 자체에 포함된 아이는 아니지만,
통상적으로 많이 쓰이는 아이라서
node.js와 웹 API에 공통적으로 포함되어 있어서,
똑같은 콘솔 API를 이용해서
node.js에서도, 브라우저 콘솔창에서도 출력할 수 있다.
Sources 탭 - 브레이크 포인트를 걸어서 디버깅할 때 유용
JavaScript의 공식 사이트:
https://www.ecma-international.org/
Welcome to Ecma International
Welcome Ecma International is an industry association founded in 1961, dedicated to the standardization of information and communication systems. We are also here: Since 1961 and continuing in full force today, Ecma International®facilitates the timely
www.ecma-international.org
↑ 여기는 개발자가 보기에는 좀 난해하다.
https://developer.mozilla.org/ko/
MDN Web Docs
MDN 웹 문서 사이트는 HTML, CSS, 및 웹 사이트와 프로그레시브 웹 앱을 위한 API를 포함한 오픈 웹 기술에 대한 정보를 제공합니다. 또한 Firefox 개발자 도구와 같은 Mozilla 제품을 위한 개발자 지향 문
developer.mozilla.org
↑ 여기에서 JavaSrcipt를 배우는 것을 추천한다.
w3schools는 공식 사이트는 아니다.
MDN이 훨씬 설명도 잘 되어 있고 예제도 많고 최신 정보도 빠르게 올라온다.
HTML에서 JavaScript를 포함할 때,
어떻게 포함하는 것이 효율적인가
(1) head 안에 포함
사용자가 html 파일을 다운로드 받았을 때
브라우저가 한줄 한줄씩 분석(parsing)한다.
(이렇게 한줄 한줄씩 분석하고 이해한 것을
CSS와 병합해서 DOM 요소로 변환하게 된다.)
이렇게 html을 쭉 파싱하다가 script 태그가 보이면
main.js를 다운받아야 된다고 이해하게 된다.
그래서 html을 파싱하는 것을 잠시 멈추고
필요한 JavaScript 파일을 서버에서 다운받아서 실행시킨 후에
다시 파싱한다.
단점: 만약 js 파일이 사이즈가 엄청 크고, 인터넷이 매우 느리다면
사용자가 우리의 웹사이트를 보는 데까지 많은 시간이 소요될 것이다.
∴ script를 head 안에 포함하는 것은 좋은 것이 아니다.
(2) body 태그 안의 제일 끝부분에 추가
브라우저가 html을 다운받아서 쭉~ 파싱해서 페이지가 준비된 후에
script를 만나서 스크립트를 fetching = 서버에서 받아오고 실행하게 된다.
→ js를 받기 전에 이미 페이지가 준비되어
사용자들이 페이지의 컨텐츠를 볼 수 있다.
단점: 만약 우리의 웹사이트가 JavaScript에 굉장히 의존적이라면
(ex. 사용자가 의미있는 컨텐츠를 보기 위해서는
이 JavaScript를 이용해서 서버에 있는 데이터를 받아온다든지,
DOM 요소를 더 예쁘게 꾸며준다든지 하는 식으로 동작하는 웹사이트)
사용자가 정상적인 페이지를 보기 전까지는
fetching하는(서버에서 JavaScript를 받아오는) 시간도 기다려야 되고
executing하는(실행하는) 시간도 기다려야 된다.
(3) head 안에 포함하되, async라는 속성값을 사용하는 것
async는 불리언 타입의 속성값이기 때문에,
선언하는 것만으로 true로 설정되어 async 옵션값을 사용할 수 있다.
async를 사용하게 되면,
브라우저가 html을 다운받아서 파싱을 하다가
async가 있으면 병렬로 js 파일을 다운받자는 명령만 해놓고 다시 파싱을 하다가
그 js 파일의 다운이 완료되면 그 때 파싱하는 것을 멈추고
다운로드된 js 파일을 실행하게 된다.
실행을 다 하고 나서 나머지 html을 파싱하게 된다.
장점: body 끝에 사용하는 것보다는
fetching이 parsing하는 동안 병렬적으로 일어나기 때문에
다운받는 시간을 절약할 수 있다.
단점1: html이 파싱되기도 전에 JavaScript가 실행되기 때문에,
만약 JavaScript 파일에서 쿼리셀렉터를 이용해서 DOM 요소를 조작한다면
조작하려는 시점에 html에 우리가 원하는 요소가 아직 정의되어 있지 않을 수 있다. → 위험
단점2: html을 parsing하는 동안에 언제든지 JavaScript를 실행하기 위해서 멈출 수 있기 때문에
사용자가 페이지를 보는데 시간이 여전히 조금 더 걸린다.
(4) head + differ
☆ Best 옵션 ☆
파싱을 하다가 script differ가 있으면 다운받으라는 명령만 해놓고
나머지 html을 끝까지 파싱한다.
파싱이 끝난 후에 다운된 Javascript를 실행한다.
※ async와 differ의 차이를 좀 더 알아보자
(3) head + async
async 옵션으로 다수의 스크립트를 다운받게 되면
정의된 스크립트 순서와는 상광 없이,
먼저 다운되는 스크립트를 먼저 실행하게 된다.
→ 만약 순서에 의존적인 JavaScript라면 문제가 될 수 있다.
(4) head + differ
먼저 다 다운받은 후에 순서대로 실행하기 때문에,
우리가 정한 순서가 지켜진다.
∴ 결론: head 안에 differ 옵션을 이용해서 쓰는 것이 제일 효율적이고 안전하다.
JavaScript를 이용할 때
제일 윗부분에 'use strict'를 정의해주면 좋다.
타입 스크립트를 쓸 때는 전혀 선언할 필요가 없는데,
순수 바닐라 JavaScript를 이용할 때는 꼭 쓰는 것이 좋다.
∵ 브랜든이 JavaScript 언어를 만들 때, 굉장히 빨리 만들어야 했다.
그래서 JavaScript는 굉장히 유연한 언어로 만들어졌다.
그런데 유연한 것은 가끔 위험할 수 있다.
유연하게 한다는 것은 개발자가 많은 실수를 할 수 있다는 말이다.
JavaScript에서는 선언되지 않은 변수에 값을 할당한다든지
기존에 존재하는 프로토타입을 변경한다든지
이런 비상식적인 점들이 있다.
use strict는 ES5에 추가되어 있다.
use strict를 선언하게 되면,
우리가 더이상 그런 비상식적인 것을 쓸 수 없게 된다.
∴ ① 조금 더 상식적인 범위 안에서 JavaScript를 이용할 수 있게 해준다.
② JavaScript 엔진이 조금 더 효율적이고 빠르게 JavaScript를 분석할 수 있기 때문에
실행하는데 있어서 조금 더 나은 성능 개선
드림코딩 by 엘리
'JavaScript > 엘리' 카테고리의 다른 글
| JavaScript/엘리 - 3. 데이터타입, let vs var, hoisting (0) | 2020.06.14 |
|---|---|
| JavaScript/엘리 - 1. JavaScript의 역사와 현재 그리고 미래 (0) | 2020.06.13 |
댓글