My Words, Your Memory

#0 자바스크립트는 무척 쉽고 강력한 스크립트 언어이지만 의외로 나를 슬프게 할 때가 있다. 이번에 이글루스의 Navi-bar 를 보고 삘 받은 김에 XUL 코딩을 좀 했는데 (사실 일하기가 싫어서 -_-) 의외로 나를 궁지에 몰아넣었던 몇 가지. 미리 경고하지만 아래 내용들을 이해할 수 있다면 당신은 자바스크립트로 코딩 좀 해본 사람이다. 누가 만든 코드 copy&paste 좀 해 본 수준으로는 아마 아래 내용을 절대 이해할 수 없을 것이다.

#1 자바스크립트에는 class 가 없고, 대신 임의의 함수를 Constructor 로 삼고, 해당 함수의 prototype attribute 를 이용해서  OOP를 한다. 클래스 기반의 OOP에 익숙한 대부분의 프로그래머들에게 이런 접근법이 과연 얼마나 효용성이 있는 것인지 모르겠다. 클래스 상속 한 번 구현하려면 머리에 쥐가 나는 아픔이 있다.

#2 자바스크립트에서는 왜 브라우저 수준의 timer 객체를 지원하지 않을까? setTimeout 또는 setInterval 함수를 이용해서 코딩을 하는데, 이 함수에 인자로 주어지는 expression 혹은 function 의 치명적인 문제점은 'scope'를 잃어버린다는 점이다. 결국 (야료를 쳐서) 해당 멤버 함수를 호출하는 anonymous function 을 만들어넣는 삽질을 하게 될 뿐 아니라, 타이머가 'fire' 되기 전에 미리 다른 곳에서 이를 캔슬시킨다거나 하는 제어를 해주는 것도 쉽지가 않다.

#3 'scope 잃어버리기' 보다 골때리는 상황은 어떤 객체에 다른 객체에 속한 함수를 callback function 으로 전달할 때. 예를 들자면, 우리가 AJAX 코딩을 하면서 많이 사용하는 XMLHttpRequest 객체의 경우에, onReadyStateChange 함수 대신 우리가 원하는 callback 함수를 쓰고자 할 때다. 이때 callback  함수가 global 이 아닌 특정 객체 내에 속한 함수인 경우... 마찬가지로 this를 쓸 수 없으며 anonymous function 으로도 해결되지 않는다. (여러가지 해결 방법이 있지만 보통 apply 함수를 이용해서 강제로 scope 를 바꿔버리거나, this 변수를 미리 다른곳에 보관해놓고 활용하거나 한다)

#4 물론 이런 개같은 경우를 위해 prototype.js 같은 훌륭한 라이브러리를 쓰는 것도 좋은 생각이다. 하지만 아무리 따져도 몇백줄 되지 않을 코드를 위해, 줄잡아 60KB를 훌쩍 넘는 prototype 라이브러리를 통째로 사용할 필요는 없지 않은가? 게다가 Prototype 은 Firefox 2.0 과 별로 궁합이 좋지 않은 것인지 때때로 말썽이 생기곤 한다.

#5 자바스크립트에는 include 문이 없다. 따라서, 코드 에디터가 execution context 를 완전히 이해하고 있지 못한 경우엔 code 자동 완성, 오류 교정등 생산성 향상을 위한 많은 기능들을 포기해야 한다. 즉 페이지에서 script 태그를 통해 include 한 다른 자바스크립트 파일들에 대해 프로그래머는 항상 많은 것들을 이해하고 있어야 한다. 적어도 PHP처럼 require 같은 게 있으면 얼마나 좋은가. 중복 include 를 한다거나 해서 사람 머리아파질 일도 없고.

#6 상황이 이렇다보니 어플리케이션의 MVC 모델을 잡기가 그리 수월치가 않다.View 야 브라우저의 DOM 구조가 해결해주는 문제지만, 이게 Data Model 까지 어떻게 해주는 건 아니니까. Control 의 어려움은 앞서 얘기한대로 event handler function 들이 다른 함수의 member 일때 scope 를 분실해버리는 관계로, Control Class 를 부여하기가 매우 난감하다. 게다가 AJAX까지 끼어들면 문제는 더욱 복잡해진다. 서버에서 받은 responseText 를 직접 evaluate 하는 식으로 덤볐다가는 context scope 를 딱히 정의할 수 없으니....