자바스크립트는 세계에서 가장 성공적이고 다재다능한 프로그래밍 언어 중 하나지만 처음부터 그랬던 것은 아니다. 지금의 자바스크립트는 자바스크립트를 만든 사람들이 원래 구상했던 언어와 완전히 다른 언어다. 그 11가지 이유를 살펴보자.
1995년 큰 꿈을 갖고 모인 소수의 프로그래머들이 자바스크립트를 출범했다. 원래 이들이 생각했던 이름은 모카(Mocha)나 라이브스크립트(LiveScript)였지만 유행에 밝았던 몇 사람이 이미 상당한 인기를 끌고 있던 자바 언어의 시류에 올라타기로 했다.
새로운 스크립팅 언어의 처음 목표는 단순해서, 정적 웹 페이지에 생명력을 좀 불어넣자는 것이었다. (당시 웹 페이지에서 움직이는 부분은 <blink> 태그밖에 없었다. 이 태그는 오래전에 사라졌지만 아직 기억하는 사람이 있을 것이다.) 그때 자바스크립트 개발자는 양식 요소를 이중으로 확인하기 위해 만들어진 아주 작은 레이어 하나가 이후 소프트웨어 배포의 주된 방식이 될 것이라고는 꿈에도 생각하지 못했을 것이다. 현재의 자바스크립트 버전에서는 이 1세대 스크립팅 언어의 흔적을 거의 찾아볼 수 없다. 오래된 코드도 대부분 웹사이트에서 여전히 실행되지만 초창기부터 지금까지 수많은 기능과 레이어가 추가됐다. 자바스크립트의 역할과 책임의 범위도 훨씬 더 커졌다. Node.js 덕분에 자바스크립트는 웹 페이지 전용을 넘어 서버측 스택의 큰 부분을 차지하면서 이제 <blink> 태그 또는 고양이 밈과는 아무런 관계도 없는 코드를 실행하고 있다. 암호화폐 애플리케이션, 의료, 주식거래 봇을 비롯한 수많은 작업이 자바스크립트에 의존한다. 30주년을 눈앞에 둔 자바스크립트 언어가 그 사이 얼마나 변했는지 돌아보자. 지금 우리가 사용하는 자바스크립트는 다음과 같은 11가지 측면에서 이 언어를 만든 이들과 초기 도입자들이 상상했던 언어와 완전히 다르다.
더 이상 자바스크립트로 불리지 않음
처음에는 모두가 자바스크립트라고 불렀다. 지금도 대부분의 개발자가 이 이름을 사용한다. 그러나 표준을 만드는 사람들이 공식적으로 사용하는 이름은 ECMA스크립트다. 일부는 규범적 언어 사양의 공식 버전 번호(최대 14)까지 명시한다. ECMA스크립트는 입에 잘 붙지 않고 따뜻한 커피를 연상시키지도 않지만 자바스크립트를 자바와 확실히 구분해준다. 이 이름을 사용함으로써 자바스크립트 개발자는 자바 상표, 로고 또는 기타 트레이드 드레스에 대해 걱정할 필요가 없다. 단, 이 사양을 유지관리 주체인 ECMA 인터내셔널(ECMA International)은 이름 옆에 작은 등록 상표 기호를 붙이는 것을 좋아한다는 점만(ECMAScript®) 예외적으로 주의하면 된다.
너무 방대해서 특정 부분의 전문화 필요
지금의 자바스크립트는 너무 방대해서 누구도, 심지어 매일 자바스크립트를 사용하는 개발자라 해도 모든 부분을 아는 것은 불가능하다. 서버 측 옵션과 동형(isomorphic) 코드의 등장으로 새로운 에너지가 유입되고 많은 개발이 이뤄져 한 사람이 브라우저 또는 서버를 위한 코드 작성의 세세한 부분을 모두 알기가 극히 어려워졌다.
이론적으로는 브라우저와 서버에서 모두 실행되는 코드를 쓸 수 있지만 현실에서 개발자는 브라우저 또는 서버 하나에 대한 전문성을 갖추는 데 집중한다. 개발자는 흔히 자신이 브라우저 기반 자바스크립트 프레임워크, 서버 측 자바스크립트, 또는 데이터베이스 측 자바스크립트를 다룬다고 구분해서 말한다. 자바스크립트 세계는 방대하다.
관건은 프레임워크
서버 세계와 브라우저 세계로 나누는 것 외에도 자바스크립트 개발자는 프레임워크 단위로 자신의 전문 분야를 좁히는 경향이 있다. 많은 구인 공고는 "자바스크립트" 프로그래머를 구하지 않는다. 이들은 리액트, 앵귤러를 비롯해 많이 사용되는 10여 개의 자바스크립트 프레임워크를 다룰 줄 아는 사람을 찾는다. 실용적인 결정이다.
프로그래머는 성공하려면 이러한 프레임워크의 세세한 특성에 정통해야 한다. 물론 자바스크립트의 기본도 알아야 한다. 그러나 앵귤러가 HTML 속성을 어떻게 사용하는지 모른다면 자바스크립트 전문 지식을 아무리 많이 갖고 있어도 도움이 되지 않는다. 앵귤러, 리액트와 같은 대형 프레임워크도 너무 커지고 복잡해져서 일부 프로그래머는 상태 관리 툴(리덕스(Redux), 몹액스(MobX)) 또는 기본 모델 옵션과 같은 자바스크립트의 하위 영역에 집중하는 더 작은 툴에 대한 전문성을 키우고 있다.
동형
자바스크립트의 인기가 큰 폭으로 늘어난 계기 중 하나는 Node.js를 통해 서버에서 실행되는 자바스크립트 코드를 작성할 수 있게 된 것이다. 한 팀이 브라우저 소프트웨어를 처리하고 다른 팀이 서버 측을 관리할 필요가 갑자기 사라졌다. 동일한 코드를 두 위치에서 동형으로 실행할 수 있게 되면서 자바스크립트 개발자는 브라우저에서 서버로, 다시 브라우저로 훨씬 더 쉽게 함수를 옮길 수 있게 됐다.
잠깐, 조금 전에 자바스크립트 세계가 두 갈래, 세 갈래 또는 그 이상으로 분화되고 있다고 말하지 않았던가? 맞다. 그러나 동형성은 여전히 가치 있다. 암호화와 같은 작업을 위한 많은 기본적인 함수는 다양한 영역에서 동일하게 실행이 가능하다. 물론 프로그래머는 한 틈새 영역에 대한 전문성을 키울 수 있지만 코드 자체는 모든 틈새 간에 아무런 제한 없이 흐를 수 있다.
다수의 새로운 연산자
원래의 자바스크립트에는 데이터 객체를 다루기 위한 간단한 기능이 몇 가지 있었다. 최신 버전은 데이터 구조를 분할하고 쪼개고 확장하고 변경할 수 있는 스프레드 연산자(…), map과 같은 추가 기능을 지원한다. 그 결과 매우 간결하면서도 매우 강력한 코드를 얻을 수 있다. 프로그래머는 복잡한 데이터 구조를 포장하고 풀기 위한 끝없는 루틴을 쓰지 않고도 손쉽게 이러한 구조를 제공할 수 있다. 코드는 더 간소하고 빠르며, 새로운 구문을 안다면 읽기도 더 쉽다.
모든 곳에 있는 JSON
초기 자바스크립트 프로그래머는 데이터를 공유하려면 파싱하고 직렬화할 수밖에 없었다. 이후 어느 영리한 사람이 네이티브 자바스크립트 객체 형식(JavaScript Object Notation, 즉 JSON)이 효율적인 동시에 속도도 빠르다는 사실을 발견했다. 자바스크립트 스택은 JSON을 사용해 저장된 데이터를 다른 대부분의 형식보다 더 빠르게 파싱할 수 있었다. 지금은 자바스크립트 코드를 쓰지 않는 프로그래머도 유연성과 효율성을 이유로 JSON 형식의 데이터를 사용한다. JSON은 모든 곳에 사용되지만, JSON을 빠르게 파싱하고 객체로 변환하는 자바스크립트 환경에 사용될 때 가장 잘 맞는 느낌이다.
빌드와 빌드 툴
초기 사람들은 텍스트 편집기로 자바스크립트를 쓰고 브라우저에서 테스트했다. 현대 자바스크립트 애플리케이션은 조금 더 복잡하다. 대부분의 경우 그런트(Grunt), 걸프(Gulp), 웹팩(Webpack)과 같이 다양한 구성요소를 최종 실행 스택으로 엮어주는 다단계 빌드 툴이 필요하다. 많은 개발자가 결국 코드를 테스트하고 충돌 가능성이 있는 버그를 확인하는 전체 CI/CD 서버를 사용하게 된다. 자바스크립트의 빌드 툴은 매우 강력해서 개발자와 일종의 애증의 관계에 있는 경우가 많다. 이들이 작성하는 코드는 분석을 거쳐 실제로 실행되는 형식으로 어셈블링되기 전까지는 아무 데서도 실행되지 않는다. 기술적으로 자바스크립트는 여전히 동적 스크립팅 언어지만 오래된 C 컴파일러보다 빌드에 더 오랜 시간이 걸리는 경우가 종종 있다.
JIT 컴파일
지금은 처리와 전처리가 스택의 위아래에서 이뤄진다. JIT(Just-In-Time) 컴파일러는 처음 등장할 때부터 자바스크립트의 잠재력을 끌어냈고 지금도 계속 개선되고 있다. 현재의 컴파일러는 코드가 실행될 때 반복적으로 이를 분석해서 대부분의 작업을 수행하는 알고리즘의 핵심 부분을 개선할 수 있을 만큼 똑똑하다. 가비지 수집에서 효과적이며 피해를 입히는 여러 가지 동작을 차단한다. 스크립팅 언어로 시작된 언어임을 감안하고 보면 자바스크립트의 JIT 레이어는 공식적으로 "컴파일되는" 언어만큼 강력해 보인다.
형식 안전성
자바스크립트 초창기 일부 프로그래머는 각 변수에 저장되는 데이터의 형식을 정의하기 위해 부가적인 입력이 필요하다는 점을 싫어했다. 여전히 기본 자바스크립트를 사용한다 해도 자유지만 이제는 상당히 많은 개발자가 타입스크립트와 기타 자바스크립트를 위한 형식 지정 옵션을 수용하고 있다. 이러한 프리프로세서는 형식 규칙, 그리고 이 규칙에 수반되는 모든 안전 장치를 적용한다.
방대한 라이브러리 생태계
오늘날 자바스크립트 생태계에는 폭과 깊이를 가늠하기 어려울 정도로 방대한 라이브러리가 번성 중이다. 수천, 수백만 가지의 애플리케이션을 위한 코드가 있다. 기본적인 프로젝트를 위한 빌드 파일도 수백 가지의 종속성을 가져올 수 있다. 자바스크립트는 깃허브, 깃랩 등의 리포지토리에서 가장 인기 있는 언어 중 하나다. 리포지토리에서 모든 경우에 맞는 코드를 며칠이고 탐색할 수 있다.
자바스크립트로 크로스 컴파일되는 다른 언어
자바스크립트의 최근 변화 하나를 꽂바면 다른 언어로 작성된 코드 지원이다. 자바스크립트로 크로스 컴파일해서 브라우저 또는 서버에서 실행할 수 있는 언어는 수백 가지에 이른다.
JIT 컴파일러 덕분에 이제 자바스크립트는 오래된 코볼 또는 새로운 하스켈을 어디서나 빠르게 실행하고자 하는 개발자에게 좋은 중간 지점 역할을 한다. 물론 이러한 언어를 좋아하는 사용자는 자체 컴파일러를 만들 수 있지만 자바스크립트로 크로스 컴파일해서 툴에 최적화를 맡기는 편이 더 쉽다. 결과적으로 많은 자바스크립트 코드가 완전히 다른 언어를 사용하는 프로그래머에 의해 작성됐다.
모바일 웹에서 뒤로가기 버튼 선택시 history.pushstate 사용해서 뒤로가기 이벤트 확인하기
모바일 웹에서 뒤로가기 버튼을 처리하려면 JavaScript를 사용하여 history.pushState를 활용할 수 있습니다. popstate 이벤트를 사용하여 뒤로가기 버튼의 클릭을 감지할 수 있습니다. 아래는 간단한 예제 코드입니다.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>뒤로가기 이벤트 확인</title>
</head>
<body>
<h1>뒤로가기 이벤트 확인</h1>
<script>
// 현재 상태 저장
history.pushState({ page: 1 }, "Title 1", "?page=1");
// 뒤로가기 이벤트 처리
window.addEventListener('popstate', function(event) {
// event.state에는 현재 상태의 데이터가 들어있습니다.
if (event.state) {
alert('뒤로가기 버튼이 눌렸습니다. 페이지 상태: ' + JSON.stringify(event.state));
} else {
// 더 이상 뒤로 갈 수 없을 때, 예를 들어 초기 페이지에서 뒤로가기 버튼을 눌렀을 때 처리할 내용을 여기에 추가할 수 있습니다.
alert('뒤로 갈 수 없습니다.');
}
});
// 새로운 상태 추가 및 주소 변경
function changeState() {
const newState = { page: 2 };
history.pushState(newState, "Title 2", "?page=2");
}
</script>
<!-- 버튼을 클릭하여 상태를 변경하고 뒤로가기 이벤트를 확인할 수 있습니다. -->
<button onclick="changeState()">새로운 상태로 이동</button>
</body>
</html>
1.마우스의 휠 버튼을 사용하는 경우 2.키보드의 커서키를 사용하는 방법 3.스크롤 바 위에 마우스를 올려 드래그하여 이동하는 방법
이처럼 세가지 방법이 가장 보편적입니다. 이 중에서 오늘은 스크롤을 사용한 이동시 이를 블락하는 방법을 알아보겠습니다. 먼저 스크롤을 막는 것이 왜? 그리고 언제 필요할까요?
# 스크롤의 이동을 막는 것이 필요한 경우 언제 스크롤을 사용한 페이지 이동을 막아야할까요? 먼저 중요한 콘텐츠 화면 영역에서 빠른 스크롤 이동에 의하여 의도한 콘텐츠를 다 못보여주는 경우도 생각해볼 수 있습니다. 이런 경우는 예를 들면... 페이지 스크롤에 따라 화면이 동적으로 변하는 웹사이트의 경우가 이에 해당합니다. 동적으로 변하는 웹사이트를 보여주기 위해 사용자의 스크롤 이동을 강제하는 것이 필요할 수 있습니다.
또 다른 이유로 스크롤이 화면에 고정되야 하는 경우입니다. 햄버거 버튼을 누른 뒤거나 아니면 모달 형식의 팝업창을 띄운 경우가 좋은 예 입니다.
# 스크롤을 고정하는 방법 예제 소스보기 아래의 소스 코드를 봐주세요. 이코드는 스크립트와 CSS를 사용하여 사용자의 페이지 이동을 강제적으로 막고 있습니다. 우선 스크롤이 생기지 않게 하기 위하여 html과 body 태그에 overflow 속성을 사용하였고 그 값으로 hidden을 주었습니다.
또한 해당하는 요소의 브라우저 기본 이벤트를 피하기 위해 아래의 이벤트 함수를 사용합니다. preventDefault()는 이벤트 내장함수의 실행을 막아 의도한 동작만을 방문자에게 보여줍니다. 또한 발생 가능한 아벤트 버블링을 피하기 위해 stopPropagation()을 추가하였습니다. 해당 자바스크립트는 아래와 같이 사용합니다. event.preventDefault(); event.stopPropagation();
아래 코드를 직접 실행해 보면서 익혀보시기 바랍니다. 코드는 제이쿼리(jQuery)를 사용하여 만든 예제소스입니다. $('html, body').css({'overflow': 'hidden', 'height': '100%'}); $('#element').on('scroll touchmove mousewheel', function(event) { event.preventDefault(); event.stopPropagation(); return false; });
위 코드는 스크롤과 터치이동, 마우스휠의 이벤트 발생시 동작하지 않도록 제거합니다. 각각 scrolll, touchmove, mousewheel 이벤트 코드가 추가되어 있습니다.
# 스크롤 이동을 다시 허용하기 만약 다시 스크롤을 허용해야한다면? 이 경우 기존의 마우스 스크롤이벤트의 핸들러를 제거해야하므로 해제방법이 필요할 것입니다. 이때는 등록된 이벤트를 해제하여 주는 off() 메소드를 사용하여 가능합니다. 아래 코드의 예제를 봐주세요. $('#element').off('scroll touchmove mousewheel');
